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ABSTRACT 


An  introduction  to  decision  looic  table  terminology^ 
structure^  theory*  and  oreprocessor  historical  development. 
Advantages  of  decision  tables  and  flowcharts  have  been  sur- 
veyed and  contrasted.  Techniques  of  decision  table  prepara- 
tion have  been  enumerated.  OELTRAfjS*  a rule  mask  logic 
table  preprocessor  for  the  C language*  has  been  proposed  for 
use  on  the  PDP-11/50  system  at  the  U.S.  Naval  Postgraduate 
School  . 
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INTRODUCT lOM 


A.  BACKGROUND 

A decision  table  preorocessoc  is  a software  program  for 
translating  decision  logic  tables  into  compilable  source 
code.  The  preprocessor  developed  by  the  authors?  aptly 
called  DELTRA^S,  was  oesioned  to  operate  on  the  PDP-ll/SO 
system  at  the  Naval  Postgraduate  School  ang  accept  C 
language  programs  containing  decision  logic  taoles.  The 
design  ot  DELTPA'jS  was  based  on  the  seguential  testing  rule 
mask  technioue  perfected  by  Press  (^OJ. 


The  use  of  this  decision  table  processor  should  reduce 
both  programmin'^  effort  anci  time.  The  additional  computer 
time  required  for  compilation  is  overshadowed  by  the  reduc- 
tion in  manpower  required  for  programming  both  during 
initial  programming  phases  and  maintenance  phases.  The  con- 
cept ang  structure  of  decision  logic  tables  causes  the 
number  of  overlooked  situations  and  program  inconsistencies 
to  be  reduced. 


Decirion  tables  offer  a stimulatino  alternative  to 
traditional  oroorammina  methods  for  those  who  are  willing  to 
educate  themselves  in  their  construction  and  use.  i t h this 
knowledae#  DELTRANS  is  but  another  tool  for  the  C 1 anquage 
programmer?  nossiblv  a very  valuable  one. 
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The  major  steos  from  oroaram  input  to  production  of 
executable  code  are  deoicted  in  Fiaure  1.  Initially/  a file 
containing  a C language  program  may  be  created  at  a 
terminal.  The  programmer  codes  those  segments  of  the  pro- 
gram not  covered  by  decision  logic  tables.  bnecial  symbols 
indicate  to  the  table  preprocessor  the  beginning  and  ending 
of  each  table.  Otherwise/  the  code  is  passed  unchanged.  At 
this  point/  a call  to  DELTflAbS  is  initiated  in  order  to  pro- 
duce compilable  source  code.  As  shown  in  Figure  1/  a table 
listing  may  also  be  obtained.  Subseouent 1 y / normal  program 
compilation  may  oe  accomplished. 

Apoenaix  A,  the  OELTRA'JS  User’s  “anua?/  was  written  as 
an  independent  document  and  as  such/  guides  a user  through 
the  steos  illustrated  in  Figure  1. 

U.  historical  DE\/ELOP'-’EbT 

1.  Development  of  tne  First  Processor 

In  the  mid-lPSOs/  General  Electric's  ''^anu  f ac  t u r i ng 
Services  Department  initiated  a research  effort  to  study  the 
manufacturing  processes  that  occur  from  the  receipt  of  a 
customer  order  through  the  production  of  the  finished  pro- 
duct. Having  recognized  that  computers  might  olav  a 
significant  role/  a search  was  begun  to  find  a satisfactory 
method  for  expressing  the  complex  logic  encountered. 
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It  soon  becane  apparent  that  available  methods  of 
describing  decisions^  such  as  formulas/  narratives/  and 
flowcharts/  were  inadequate.  The  efforts  of  the  oro/ect 
team  to  discover  a new  methoo  of  expression  culminated  in 
the  development  of  "decision  structure  tables"  (181.  These 
tables  had  a format  similar  to  the  truth  tables  fromwhich 
they  orininated. 

The  Processor  for  solvino  these  tables/  expressed  in 
a language  called  TiBSOL/  operated  initially  on  an  70?, 
Later  it  was  successively  implemented  on  an  IBM  30B/  o50, 
and  70a.  In  early  l‘?ol/  an  imoroved  version  of  t^e  proces- 
sor ana  TABSOL  were  implemented  on  the  GE  ?25. 

During  this  same  time  Period/  Sutherland  Management 
Consultants  also  oeaan  experimenting  with  decision  tables 
(181.  Trey  produced  a table  different  in  form  but  identical 
in  concept.  The  emphasis  was  placed  strictly  on  the  use  of 
decision  tables  as  an  aid  to  systems  documentation/  leaving 
the  solution  of  the  table  to  the  programmer. 

A number  of  companies/  including  Hunt  EoodS/  Morth 
American  Aviation/  and  the  Insurance  Company  of  North  Amer- 
ica/ initiated  research  on  decision  tables  (111/  primarily 
to  facilitate  in-house  file-maintenance  and  system  aocumen- 
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From  1^960#  the  COOASYL  systems  study  grouc  has  car- 
ried out  work  on  the  deyelopment  of  a hiah-level  language/ 
COSCL.  Decision  tables  were  selected  as  an  addition  to 
COBOL  and  in  the  snec  i f i cat  i ons  of  DETAB-X  were  pub- 
lished. The  manual  described  a decision  table  preprocessor 
that  could  accept  the  decision  tables  as  input  and  produce  a 
form  of  COBOL  coding  as  output.  This  was  the  first  table 
processor  available  to  computer  users. 


2.  Evolution  ann  Refinement 


In  June  1965/  the  Special  Interest  Grouo  for  Pro- 
gramming Languages  (SIGPLATi)  of  the  Los  Angeles  Chapter  of 
the  Association  of  Computing  N'achinery  apoointeo  a working 
group  to  develop  a decision  table  p r en r oc esso r . The  result 
was  the  distribution  of  0ETAB/b5f  written  in  a restricted 
subset  of  COBOL.  Although  imolemented  on  the  CDC  3b00  and 
IBM  70da,  among  others/  its  inefficient  conversion  algorithm 
led  to  its  demise. 


It  has  become  evident  that  OETAB/oS  waS/  however/ 
the  ancestor  of  tne  current  group  of  proprietary  decision 
table  preprocessors  developed  since  l'9bo.  Generally/  the 
processors  follow  the  OETA0/b5  lead  in  that  they  are  a 
oreorocessor  written  in  COBOL  that  converts  decision  tables 
containing  COBOL  components  to  a stream  of  COBOL  source  code 
suitable  for  comp i 1 a t i on . There  are  several  exceptions  to 
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this  basic  rule 


IBM's  System/3bO  Decision  Logic  Translator  processes 


decision  tables  coded  in  Fortran.  There  are  also  other  not- 
able exairples  using  BASIC  and  ALGOL  llSl  . Some 
preprocessors  offer  the  programmer  the  ootion  of  specifying 
the  language  to  be  processed. 

3.  Use  Today 

A review  of  decision  logic  table  preprocessor  his- 
tory almost  forces  one  to  wonder  why  decision  looic  tables 
are  not  universally  used  for  systems  analysis#  program 
development#  and  documentation.  '■^any  times#  this  techniaue 
has  succeeded  where  the  more  wioely  used  methods  of  narra- 
tive and  flowcharting  have  failed.  i'lhy  then  nas  the  use  of 
decision  logic  tables  not  been  more  widespread? 

Thre®  possible  causes  have  been  identified.  First# 
the  amount  of  information  available  to  systems  analysts  and 
programmers  on  a daily  oasis  has  been  limited.  Although 
many  articles  have  been  published  over  the  years#  they  have 
generally  appeared  in  highly  technical  form  or  have  appeared 
in  proceedings  or  journals  not  extensively  circulated  to  the 
commercial  o r ac t i t i one r . As  a rule,  decision  tables  have 
not  been  tauoht  in  their  riohtful  place  as  an  alternative  to 
flowcharts  in  introductory  programming  courses. 

Second#  the  use  of  decision  taples  reouires  a dif- 
ferent approach  to  rroolem  solving  than  does  flowcharting. 


Flowchartinq  leads  one  to  adoot  a sequential  model  o^  deci- 
sion makinq.  That  is»  a test  followed  by  one  or  more 
actions.  On  the  other  hand,  decision  loqic  tables  require 
an  overall  analysis  of  the  conditions  that  comorise  a given 
oroblem  and  the  effect  of  their  various  combinations  on  the 
solution.  Natiirally»  there  is  much  resistance  among  those 
trained  in  seauential  tyoe  analysis  to  accept  a new  tech- 
n i que . 

Third,  there  has  been  a qeneral  lack  of  decision 
table  processors  available  to  the  data  processinq  community, 
fls  a result,  tables  had  to  oe  nanq  translated  to  sequential 
code  for  incut  to  the  computer.  Absence  of  a mechanized 
means  of  translation  has  resulted  in  a rapid  decrease  of 
interest  in  decision  tables  by  programmers. 


These  three  conditions  are  slowly  being  eased  with 
the  increase  of  books  and  articles  published  on  the  subject. 
Seminars  are  available  from  several  sources  and  presumably, 
the  historical  resistance  to  decision  tables  will  be  over- 
come . 


C.  FLOWCHARTING  VERSUS  OF.CISTON  TABLES 

As  has  been  pointed  out.  narratives  and  tlowcharting 
have  historically  been  used  to  document  computer  programs 
and  structure  their  lodic.  These  techniques  have  t)een 
demonstrat"d  to  b®  very  etf®ctive  time  and  time  aoain.  as 
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long  as  the  problem  retainer)  relatively  simole  and 
forward.  However^  this  effectiveness  has 
deteriorated  when  the  problem  became  more  complex. 


straight- 
severe  1 y 


Decision  logic  tables  have  been  shown  to  provide  a for- 
mat for  organizing  and  displaying  program  logic»  and  have 
been  compared  with  narratives  and  flowcharts  in  program 
documentation  and  Iodic  structuring.  This  comparison  has 
shown  a number  of  important  advantages  and  disadvantages  of 
the  use  of  decision  Icaic  tables. 


One  advantage  of  oecision  loaic  tables  over  other  forms 
is  the  conciseness  normally  associated  with  a decision 
table.  * much  larger  amount  of  information  may  be  placed  in 
a given  soace  using  a table  as  opposed  to  narratives  or 
flowcharts.  This  dense  display  of  information  provides  a 
much  clearer  representation  of  the  program  logic  than  a 
cloudy  narrative  or  a branching,  meandering  flowchart. 

The  conciseness  of  decision  logic  tables  leads  directly 
to  tneir  second  advantage.  'Jamely,  the  advantaae  of 
thorouahness  or  completeness.  The  person  preparing  decision 
logic  tables  is  forced  by  their  format  to  consider  all  pos- 
sible combinations  of  events.  This  is  quite  different  from 
the  flowcharting  anproach  which  tends  to  emphasize  sequen- 
tial I'Oaic  flow.  This  emphasis  on  sequential  logic  flow 
often  tenas  to  obscure  alternative  logic,  and  mav  thoroughly 
avoid  the  issue  of  Ionic  c omp  1 <»  t ene  s s . Failing  to  be 
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orepareci  for  all  possible  combinations  of  events  is  of 
course  a major  source  of  subtle  program  "bugs". 


Non-seouential  loaic  flow  also  tends  to  assist  tbe  pro- 
grammer in  eliminating  otner  logic  errors.  The  elimination 
is  due  to  the  manner  the  entire  flow  of  logic  is  displayed 
at  a alance  in  the  case  of  decision  logic  tables.  The  pro- 
grammer is  thus  permitted  to  visualize  better  the  interrela- 
tionships and  alternatives  within  the  problem  at  hand.  Not 
only  is  completeness  displayed  Put  also  redundant  tests  are 
pinpointea  thus  permitting  the  production  of  more  efficient 
code . 

Oecision  loaic  table  construction  and  modification  is 
easy  to  learn.  TnuSf  a non-orogrammer  can  normally  read  the 
logic  of  a well  written  orogram.  Further#  dependency  upon 
the  orioinal  Drogramrer  is  areatlv  reduced  since  modifica- 
tions are  easy  to  perform. 

A final  important  advantage  of  decision  logic  tables 
over  flowcharting  is  their  ability  to  serve  as  computer 
input.  This  permits  machine  checking  for  certain  types  of 
logic  errors  and  mechanized  conversion  into  a program  seg- 
ment . 

Several  disadvantages  to  the  user  of  decision  logic 
tables  do  exist.  Perhaps  the  most  insidious  is  that  the 
seauential  flow  of  flowcharting  has  been  the  only  technigue 
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tauqht  oroaranitT'ePS.  The  effort  to  team  something  "new"  has 
only  been  reluctantly  taken  in  may  cases. 


Another  drawback  is  that  although  it  is  easy  to  learn  to 
use  decision  logic  tables/  extensive  work  is  required  to 
become  truly  efficient  in  programming  with  them/  as  opposed 
to  programming  with  flowcharts.  when  using  a computer  to 
convert  the  logic/  further  work  is  required  to  become 
familiar  with  the  translator  or  preprocessor. 


Even  though  the  flow  of  logic  is  improves/  the  actions 
specified  cannot  be  machine  checxed  to  ensure  they  are 
correct/  or  even  feasible  for  that  matter.  Also/  the 
machine  is  incapable  of  recognizing  impossible  combinations 
of  events.  Ibis  forces  the  programmer  to  perform  these 
checks  or  Supply  some  escaoe  set  of  actions. 


The  advantages  and  disadvantages  of  decision  logic 
tables  discussed  here  have  been  summarized  in  Table  1.  They 
may  be  compared  with  those  of  flowcharts  that  have  been 
listed  in  Table  2. 


Clearly/  decision  logic  tables  are  not  a panacea  for  all 
the  ills  pf  data  processing  today.  However/  they  can  be 
used  as  a very  effective  tool  to  ensure  proper  program  logic 
flow  and  should  be  used  in  conjunction  with  narratives  and 
flowcharts/  as  appropriate. 
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ADVANTAGES: 

1.  Clear  enumeration  of  all  operations  performed. 

B . Clear  identification  of  the  seauence  of  operations. 

5.  Easily  learned. 

y.  Effective  means  of  communication  between  people  in  ano 
out  of  data  processino. 

5.  Concise  and  compact  form  of  documentation, 
ti . Easy  to  constructf  modify  and  read. 

7.  Easy  v i sua I i za t i on  of  relationships  and  alternatives, 
ft.  Directly  adactaole  to  computer  operations. 

DISADVANTAGES: 

1.  "''ay  be  larae  for  complex  situations. 

2.  'Multiple  tables  may  be  needed. 

3.  Cfraphic  display  of  flowcharts  may  be  more  meaninqful. 
y.  Peduirements  too  detailed  for  man-tO“man  communication. 


. Advantaaes  ano  D i s adv an t aae s of  Decision  Tables 

1 « 


TAbLE  1 
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AD>/4, 'STAGES: 


Easily  produced. 

Easily  learned. 

Can  describe  oata  handlina  and  computer  operations. 
Can  be  produced  by  computer  alaorithms  from  source 
proqrams  . 


OISADVAtiTAGES: 

Heavily  influenced  by  personal  preference. 
f^ay  be  difficult  to  follow  in  complex  problem. 
►Revision  is  difficult. 

Limited  in  displayinq  all  looical  elements. 
Detailed  logic  flowcharts  are  unwieldy. 


TA8LE  2.  Advantaces  and  D i sadvant ages  of  Clowcharts 
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II.  lh:cisioi^  table  structure 

This  section  is  intended  to  introduce  decision  logic 
tables  bv  describing  their  structure  and  the  rules  governing 
their  use.  Simoly  stated.  a decision  logic  table  is  a 
tabular  reoresent at i on  oT  all  elements  of  a problem  from 
conception  to  solution.  Information  displayed  in  this 
manner  is  easily  comprehended  even  when  the  table  of  infor- 
mation represents  a complex  logical  problem.  The  logic  used 
in  decision  fables  is  s i t i ) ar  to  that  which  is  used  every 
day.  with  or  without  the  aid  of  the  computer. 

A.  THE  ELEi^ENTS  OF  A TABLE 

tie  fore  describing  in  detail  the  table  itself.  several 
definitions  must  be  made  clear.  First,  a decision  rule  is  a 
statement  thah  prescribes  the  set  of  conditions  that  must  be 
satisfied  in  order  that  a series  of  actions  be  taken.  For 
example,  the  following  is  a decision  rule: 

If  a laborer  works  more  than  UO  hours  in  a week, 
he  must  be  paid  his  regular  salary  rate  plus  the 
product  of  his  overtime  hours  times  his  hours  in 
excess  of  ^0. 
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The  oecision  )ocjic  f3h)e  is  used  fo  describe  the  possible 
decis»ori  Pules  derived  above.  That  is/  whether  or  not  the 
laborer  worked  more  than  UO  hours  in  a aiven  week. 

The  decision  table  itS(?M  is  a structure  Tor  aescribinq 
a set  of  related  rules.  Alrhouoh  other  formats  of  decision 
taoles  exist,  some  of  which  are  easier  to  use  (18],  they  are 
all  Permutations  of  the  ()asic  format  shown  in  Fiaure  2. 


CONDITION 

CONDITION 

STUB 

ENTRY 

ACTION 

ACTION 

STUB 

ENTRY 

^IGU^IE  Decision  Table  Structure 


fts  illustrated,  the  table  is  divided  into  four 
Quadrants.  The  uoner  left  quadrant,  called  the  condition 
stub,  contains  all  the  conditions  oeinq  considered  for  a 
particular  decision  rule.  The  condition  entry,  in  the  uocer 
riqhf  quadrant,  comoines  with  t-he  condition  stub  to  form  the 
condition  that  is  to  be  tested. 

,^1 


In  the  lower  left  ausdrantr  is  the  action  stub 


It 


con- 


tains a siriole  staterrent  of  the  actions  resulting  from  from 
the  conditions  listed  above  the  horizontal  line.  Action 
entries  are  disolavec  in  the  lower  right  Quadrant.  In  this 
guaorant»  the  aporooriate  action  resulting  from  the  various 
combinations  of  responses  to  the  conditions  will  be  indi- 
cated. 


As  Shown  in  Figure  5, 

the  table 

also 

contains  a 

sect 

called  a table  header. 

Actual  1 V > 

this 

i den  t i tying 

data 

reauired  in  order  to  oist 

i n q u i S h it 

f rom 

all  other  tables 

a g 1 ven  j ob  . 

TABLE  HEADER  RULE  HEADER 


R1 

R2 

R3 

R4 

Cl 

C2 

C3 

A1 

A2 

A3 

FIL^U'^K  5.  basic  Fleirents  of  a Decision  Table 
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The  inforrration  that  fright  he  found  in  a table  header 
includes  a table  nur-Der/  a table  nanie»  the  table  tvce»  the 
number  of  rules»  conditions  and  actions/  and  any  other 
options  locally  established  to  sirrolify  translation. 

The  various  combinations  of  resoonses  to  conditions 
shown  in  the  condition  entry  Quadrant  are  called  rules  or 
paths.  Each  is  qiven  a number  for  identification  Purposes 
in  the  rule  header  oortion  of  the  table. 

B.  TABLE  Ei^TRIES 

ff  a condition  in  the  condition  stub  is  true/  a Y is 
entered  for  that  particular  rule  in  the  condition  entry. 
Conversely/  if  the  condition  is  false/  an  f>i  would  be 
entered.  /(here  irrelevant  situations  occur/  a ''don't“care" 
is  indicated  by  a dash  (-1. 


Additionally/  two  other  entries  have  been  proposed  to 


indicate  mutual  exclusion 


one  condition  with  another 


flfi/BJ.  If  the  case  arises  within  a sinqle  rule  that  the 
satisfaction  of  some  test,  indicated  by  a Y or  N entry/ 
makes  some  other  entry  a foreaone  conclusion/  then  the 


spec i a 1 entries 


o r 


may  be  used  to  indicate  this 


fact.  The  symbol  is  used  in  place  of  an  N entry  under 

these  circumstances/  while  the  is  usea  in  place  of  a Y 


entry 


The  network  algorithms  and  several  sophisticated  aloo- 
rithms  that  attemot  to  minimize  execution  time  of  the 
translated  table  and/or  provide  completeness  checkinn  make 
excellent  use  of  these  implied  truth  values.  Those  algo- 
rithms provide  completeness  checkin cj  which  accounts  for  the 
logically  imoossible  rules  introduced  by  condition  depen- 
dency. 

In  the  action  entry  quadrant/  an  X is  entered  to  indi- 
cate that  action  which  is  to  be  executed  for  a particular 


rule. 

Any  q 1 ven 

action  may 

he  executed 

for  any 

numbe  r 

0 f 

r u 1 e s / 

0 ^ 8 V ^ r 

a rule  may 

renuire  more 

than  one 

action 

and 

where  an  X is  entered  for  each  action  in  the  action  entry 
ouadrant  . 

C.  TYPES  OF  TaeLES 

There  are  three  types  of  decision  tables  in  current  use. 
The  limited  entry  table  is  the  most  popular  and  most  often 
used  (h).  Since  the  other  two  table  types/  extended  entry 
and  mixeo  entry/  may  always  be  transformed  into  limited 
entry  tables/  the  preprocessor  developed  here  allows  only 
limited  entry  table  input.  The  other  two  types  of  tables 
will  be  discussed/  however. 

1.  Limited  Entry  Tables 

The  rules  reaardina  the  placement  of  information  in 
each  of  fhe  four  cuadrants  of  a limited  entry  table  are 


fixed  and  inflexible.  The  condition  and  its  state  rnyst  be 
restricted  to  the  condition  stub.  The  condition  entry  r^ay 
only  show  the  response  Y (true)»  N (fa1se)»  * (irrplicit  N), 
T (imolicit  Y)  or  (don't  care). 

Likewisof  soecific  actions  must  be  fully  identified 
within  the  ac t i on  stub  and  permissible  notations  within  the 
action  entry  sections  are  limited  to  an  'X'  or  a blank. 

Table  5 shows  a limited  entry  table  in  crooer  for- 
mat. Note  that  entries  prescribed  for  one  Quadrant  may  not 
extend  into  another  and  that  every  condition  entry  contains 
one  ana  only  onp  of  the  allowed  symbols.  Normally*  limited 
entry  tables  are  the  b“st  suited  to  computer  applications 
115). 


TflbLE  5.  Limited  Entry  Table 
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Extended  Entry  Tables 


In  extended  entry  tables#  the  variables  to  be  tested 
are  identified  in  the  condition  stub#  while  the  condition 
entry  n^ust  define  th«*  value  or  state  of  the  variable.  Like* 
wise#  in  this  tyoe  of  table#  the  action  stub  names  an  action 
while  the  action  entry  will  dive  the  scecifics  for  the 
action  named . 

As  shown  in  table  3#  the  format  is  not  Quite  as  .1 

strict  for  this  type  of  table.  The  use  of  this  format  may 
also  tend  to  decrease  the  number  of  items  in  both  the  condi- 
tion and  action  stubs. 


LOAN  TABLE 

R1 

R2 

R3 

R4 

CREDIT 

LIMIT 

OK 

OK 

TOO 

LOW 

TOO 

LOW 

PAY 

EXPERIENCE 

OK 

POOR 

OK 

POOR 

LOAN 

APPROVE 

REJECT 

APPROVE 

REJECT 

3.  Mixea  Entry  Taoles 

Thp  mixed  entry  table  is  a combination  the  lim- 
ited entry  form  and  the  extended  entry  form.  Even  thouoh 
these  two  forms  may  be  comoined»  one  form  must  be  used 
exclusively  within  each  horizontal  row  of  a table.  Table  5 
depicts  the  information  from  the  previously  used  tables  as  a 
mixed  entry  table. 


LOAN  TABLE 

R1 

R2 

R3 

R4 

CREDIT  LIMIT 

OK 

OK 

TOO 

LOW 

TOO 

LOW 

FAVORABLE 
PAY  EXPERIENCE 

Y 

N 

Y 

N 

APPROVE  loan 


REJECT  LOAN 


table  5.  ''ixed  Entry  Table 
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III.  DECISION  table  theory 


The  uses  for  decision  tables  vary  qreatly  throuahout 
the  fields  of  business/  science/  ana  engineering.  Whatever 
their  purpose/  a sound  theoretical  basis  is  needed  to 
explore  further  the  intricacies  of  their  potential.  This 
section  is  dedicated  to  fulfillina  that  need  with  a general 
overview  of  the  bacifaround  theory  of  decision  logic  tables 
and  specific  treatTent  of  rule  'ras*>'  theories.  This  discus- 
sion is  a prelude  to  the  torics  of  table  cofrc  1 et  eness  and 
decision  rule  contradiction  arg  redundancy. 

A.  GEtiERAL 

As  previously  stated/  a decision  table  is  'raoe  up  of  a 
set  of  conditions/  each  cf  which  may  be  evaluated  as  true  or 
false  at  any  given  time.  The  truth  or  falsity  of  these  con- 
ditions may  be  combined  in  various  ways/  along  with  a series 
of  actions/  to  form  a decision  rule. 

The  series  of  actions  contained  in  a particular  decision 
rule  are  executed  when  a transaction  is  evaluated  that 
matches  the  particular  combination  of  truth  or  falsitv  of 
the  conditions  indicated  by  the  particular  rule. 


£^8 


The  decision  tables  presented  here  are  based  on  one  of 


the  boolean  aloebra  functions  known  as  the  AND  function.  It 
is  considered  to  be  the  ordered  set  of  Y's»  N's»  or  dashes 
that  appear  as  the  condition  entries  for  a particular  deci- 
sion rule.  The  application  of  the  OR  function  can  also  be 
made  in  decision  tables  and  it  is  described  in  some  detail 
by  Pollack*  et  ai.ilPJ. 

In  order  to  illustrate  the  function*  the  followino 
table  is  presented  with  its  associated  A\Q  functions. 


R1 

R2 

R3 

wEsm 

TYPE>60  WPM 

Y 

Y 

Y 

N 

SH0RTHAND>90 

Y 

Y 

N 

— 

SALARY^  $5500 

Y 

N 

— 

— 

HIRE 

X 

DO  NOT  HIRE 

X 

X 

REFER  TO 
TYPING  POOL 

X 

AND  function  I = Y*Y*Y 
Ai'jO  function  ^ = Y*Y*N 
AND  function  5 = Y*N*- 
AR'C  function  4 = M*-*- 

FIGURF.  AMD  Function  Fxamnles 


fiasicallv/  to  determine  ^.hether  or  not  a Decision  rule 


is  satisfied*  evaluate  the  AND  function  for  that  rule*  and 
check  that  it  eauals  the  reauired  transaction.  For  example* 
the  and  function  of  rule  3 would  be  satisfieo  if  the  job 
applicant  could  type  60  or  more  words  rer  minute  but  could 
not  take  dictation  at  a speed  areater  than  NO  words  per 
minute.  For  this  rule*  condition  3*  the  possible  salary*  is 
of  no  conseauence  to  the  ultim.ate  satisfaction  of  the  rule. 


B.  CONDITIONS 


So  far*  the  word  condition  has  been  used  numerous  times 
without  a conplete  definition.  A condition  is  a variaole 
factor  affertina  the  actionfs)  to  be  taken  in  a given  situa- 
tion by  its  presence*  absence,  or  change  in  value.  Series 
of  conditions  with  their  associated  rule  entries  make  up*  in 
part*  decision  looic  tables.  The  symbol  n will  be  used  to 

represent  the  number  of  conaitions*  each  denoted  by  "C  "* 

1 

"C  "*  etc.*  present  in  the  table. 

hhen  a table  is  evaluated*  the  various  conditions  are 
found  to  be  either  true  or  false.  This  truth  value  is 
stored  in  a matrix  '■*  according  to  th»  following  code  pro- 
posed by  HresslPOl. 


= 1 ang  w = 0 inrlies  the  condition  is  true 

i * 1 1 * ? 


■'>1  = 0 and  = 1 implies  t^e  congition  is  false 

i * 1 1 • ^ 


r 

! 

i 

ThereforCf  for 
be  formed; 


i 

i 

! 

i 

I 

j E^c^’VPCtorcft^e 

i 

* 1.  Structure  of  Con:Jjtions 

tact'  condition  is  most  often  made  uo  of  two  ooeraros 
related  by  a relational  coerator.  For  incut  to  the  orenro- 
cessor  develooed  here»  the  conditions  must  eacr  ne  qrammati- 
callv  correct  C lanouaoe  excressions.  For  instance^  in  its 
most  basic  form,  one  ooerand  in  a condition  statement  must 
be  a variable^  wnile  t^'e  other  mav  be  a constant  or  vcari- 
able.  The  relational  ooerators  may  be  any  one  of  the  fol” 
lowinq  C lanouace  ooerators: 

==  <=  >=  < > 1= 

1 

I 

For  oxample,  cnnsider  the  toMowinq  three  conditions 
' »n  which  a variable  is  ccmrared  to  an  intener: 

^ 1 


N conditions  the  followinq  matrix  w would 


M 

M 

1,1 

1,2 

IV. 

M 

2,  1 

2,2 

w 

M 

5,  1 

3,2 

• 

• 

• 

• 

• 

• 

M 

M 

n , 1 

n , 2 

matrix  thus  formed  is  called  a mask. 


C ; X < 1 0 
1 


C : y >=  IS 


C : 2 1=  0 
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At  the  ti'Tip  of  evaluation,  the  truth  value  is  determined  for 

each  C . Given  that  x = S,  y = 20,  ana  z = 0,  the  following 
i 

matrix  containing  two  nioDxs  would  be  obtained: 


I 0 
1 0 
0 1 


Condition  statements  may  also  be  made  ur  of 
subroutine  calls  or  variables  or  even  any  combination  of 
these  seoarated  by  locical  operators.  Thev  must,  however, 
evaluate  as  looically  true  or  false. 


2.  Condition  Deoendency 


between  any  two  Pairs  of  conditions,  there  exists 
either  dependence  or  independence.  basically,  two  condi- 
tions are  dependent  if  they  both  have  the  same  condition 
variaole  as  an  operand.  Conversely,  two  conditions  are 
independent  if  there  is  no  common  Condition  variable  used  as 
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an  operand 


There  are  two  tyoes  of  deo^noence.  Firsts  there  is 
mutual  exclusion  dependency.  This  case  occurs  when  for  any 
pair  of  conditions  C and  C f there  is  no  value  of  the  com- 

i j 

mon  condition  variable  such  that  their  mask  entries  are  both 
eaual  true.  however^  this  is  not  to  say  that  both 
conditions  may  not  be  false  at  the  same  time. 

By  extention  to  more  than  two  conditions»  it  may  be 
said  that  any  number  of  conditions  are  mutually  exclusive  if 
at  any  point  in  time  every  two  conditions  in  each  of  the 
pairs  of  conditions  are  mutually  exclusive. 

The  second  type  of  dependency  is  termed  overlappinq 
dependency.  Overlapping  dependency  occurs  when  there  can 
exist  at  least  one  value  of  a condition  variable  common  to  a 
pair  of  conditions  such  that  both  conditions  are  true. 
Other  combinations  of  truth  and  falsity  may  also  occur. 
Condition  rieoendency  thus  dictates  that  certain  combinations 
of  condition  values  are  impossible  events.  These  impossible 
events  represent  imoossible  rules  and  need  not  be  considered 
by  tbe  prodrammer  when  describino  the  proqram  looic.  How- 
ever»  machine  checking  for  condition  dependency  is  seldom 
imolemented  in  translation  aloorithms.  This  causes  the 
machine  to  interpret  the  decision  logic  table  as  being 
1 ncomp 1 et  e . 


3^ 


3.  Condition  Entry  Notation 


The  condition  entry  portion  of 
tains  one  of  the  following  entries  for 
have  the  meaning  oiven: 


a decision  table  con- 

a condition  C t which 
i 


=>  C is  reauired  to  be  true. 


N'  =>  C is  renuired  to  be  false, 


=>  C is  immaterial, 
i 

=>  C is  false,  if  some  other  explicit 
i 

condition  is  proven. 


' ' =>  C is  true,  if  some  other  explicit 

1 

condition  is  oroven. 

In  the  arquments  to  follow,  the  dash  or  will  be 

semotei  by  I for  a condition  C . where  the  condition  is 
i i 

immaterial  anq  C neeo  not  be  proven  either  true  or  false. 
1 

fit  It  should  be  pointed  out  that 


I = Y ♦ M 
i i i 

♦ i>5  an  inclusive  (JR 

Analonously.  tie  symbols  and  'f'  indicate  that 

renpa^ont  reed  not  he  proven  false  or 

lU 


the  condition  they 


r 


true,  Thpy  irroHcitly  rerrpsent  both  Y and  N for  a condi- 

f » 

t i on  C and  thus  have  the  full  power  of  bothf  if  tested, 
i 


C.  ANiD  FUtJCTIONS 


In  the  discussion  to  fo11nw»  an  ANiD  function^ 
be  considered  to  be  defined  as: 


j 


w i 1 ' 


8 = lY 

».  W i 

• • • « 

. K 

Y; 

i 1 * 

j 

3,j 

n , i 

Y. h e r e »'/  is  a vector 
i 

condition  entries 

representinq  any 

one 

o f 

the  possible 

for 

condition  i 

and 

' & ' 

is  the  Boolean 

operator  AflD. 


Each  independent  condition  nay  reouire  W to  be  Y , b . 

i i i 

or  I . Dependent  conditions  may  take  on  the  implicit 
j 

requirements  • and  ? / but  these  are  special  cases  of  f 
i i i 

ana  N » respectively.  Tnerefore  ‘Y  may  be  expressed  in  one 
i i 

of  three  states:  Y , or  I . Thus,  the  number  of  oossi- 

i i in 

pie  forms  of  an  AroD  function  is  3 . 


Recall  that  the  matrix  N'  represents  the  truth  or  falsity 
of  n conditions.  Given  a particular  matrix  it  may  be 

determined  for  w whether  V(B  )»  the  loqical  value  of  13  . 

j i 

eoua's  1 or  0 by  first  m a kino  approoriate  entries  for  each 
W of  B r accordinp  to  the  rules  indicated  in  Fiaure  b. 

i ' j i 

For  example,  suppose 


and 


H = (Y  Y D * r Y) 

i 
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V - 


Then,  according  to  the  replacements  inaicateo  in  Figure 
5,  we  have 


e =(101111) 
j 


Therefore,  V(B  ) 
j 

1 ' s , the  logical 


= 0. 

value 


Had  the  resulttng  h contained 

j 

V(d  ),  would  have  been  1. 


j 


al  1 


.■<  V(C)  Beplacewith 

< f j ^ 


r 

Y 

I'J 

rj 

* 

* 

$ 

$ 

I 

I 


0 1 
1 0 
0 1 
1 0 
0 1 
1 0 
0 1 
1 0 
0 1 
1 0 


0 

1 

1 

0 

1 

1 

1 

1 

1 

1 


FIGURE  5.  Table  ot  Her  1 ac emen t s ter  Determining  VCR  ) 

j 


3n 


1 

1 


i 


1 


As  an  e*a'"r1e,  consi^lpr  anain  t^e  followinq  conditions 


C;»<1  C:y>=lS  C:7l=0 

1 ? 3 


Given  tnat  * = S » y - 20,  and  7 = 0,  the  foIIov»ina  matrix 
was  obtained: 

1 u 
t 0 

0 1 


From  a typical  decision  table  that  nay  be  easily  formed,  the 

followinq  A*)D  function  is  oresent: 

M = ( Y Y t ) 

1 

Again,  according  to  the  r eo 1 ac emen t s indicated  in  Figure 
h , we  ob  t a i n 


R =(110) 
1 


And  V(B  ) = 0.  The  first  A 'ID  function  tested  is  not  satis- 

1 

fied  and  its  associated  action(s)  will  not  be  done.  Another 
function  must  be  considered. 


1.  Oeoenoencv  of  AMD  Functions 


Dependency  among  AMD  functions  is  somewhat  different 

than  that  among  conditions.  Two  AMO  functions,  B and  B , 

i j 

are  dependent  if  for  at  least  one  set  of  values  of  the 
conditions  variables  and  requirements,  both  v(H  ) = 1 and 


37 


V(8  ) = 1.  Utherwisef  tne  **'0  functions  are  indepenaent  and 
i 

no  one  set  of  the  conoition  variables  set  V(R  ) and  V(B  ) to 


For  exaTipler  consider  the  following  two  AND  func~ 

t i ons  : 


8 = Y , Y , Y , N 

I ■ 


['  - Y , Y , Y , N 


Then  for  a set  of  values  ot  tne  condition  variables  that 


V i e 1 os 


M = 1 0 


both  V(B  ) = 1 and  V(H  ) = 1.  Thus,  6 and  8 are  depen- 

5 a 5 a 

dent.  Had  either  V(B  ) = 0 or  V(0  ) = 0,  then  B and  H 

3 a 3 a 

would  have  been  founo  to  be  independent. 


3 , Definitions 


A Pure  AND  function  is  one  that  contains  no  "1 


entrv.  For  exar'ole. 


P = Y , * , 


is  a pure  A^ID  function 


i 

i I 


A decision  rule  is  simple  if  it  contains  a Pure  Af\iD 
function.  A rrixod  Ai\0  function  is  one  that  contains  one  or 
more  I's.  A decision  rule  is  complex  (or  compound)  if  it 
contains  a mixed  A^ID  function, 

D.  rHEOREf-’S  FOR  AMD  FUMCTIOMS 

In  tt>e  theorems  that  follow,  a taole,  T,  is  assumed  to 
comprise  all  Af;0  functions  that  can  Generate  from  the  condi- 
tions of  that  table.  The  theorems  are  presented  for  infor- 
mational purposes  only.  Detailed  proofs  are  presented  by 
Pollack  llFl, 

ToFOREr’  I.  within  table  T,  two  AND  functions  are 
i noeoenneot  if,  in  at  least  one  position,  one  func- 
tion contains  a V and  the  other  function  contains  a 
D.  Otherwise,  tney  are  dependent. 

For  an  illustration  of  theorem  I,  consider  the  following 
i nc  omp lete  table. 


XQ 


least  one  Y,''i  oair 


AF2  and  AF3  are  indeoendent  because  a Y » fj  pair  exists 


for  condi t i on  C . 

? 


THFOWE^^  II.  Aithin  table  T,  each  pure  AI'JD  function 
is  inoeoennent  of  every  other  pure  AND  function. 

Consider  the  foHowino  table  for  an  illustration  of 
theorem  II, 


AFl 

AF2 

AF3 

AF4 

Cl 

Y 

Y 

N 

N 

C2 

Y 

N 

Y 

N 

By  definition,  all  four  A-'lt)  functions  are  pure.  Prom 
theorem  I,  they  are  in  leoenoent.  In  this  example,  there  are 
no  other  pure  ATjD  functions  Possible  and  therefore  each  pure 
AND  function  is  inoepenoent  of  every  other  pure  AfjD  func” 
t i o n . 

TH^OPE’''  III,  •lithin  table  T,  every  mixed  AND  furc~ 

t i on  that  contains  I in  positions  (1  <=  r < n)  ts 

r 

dependent  on  each  of  P pure  A^.D  functions  of  I. 


Consioer  the  followino  partial  table. 


AFl 


Y 


N 


AF2 


Y 


Y 


Y 


AFl  exoands  to  contain  the  following  cure  Af.O  functions 


AFta 

AF  lb 

Y 

Y 

M 

Y 

fkl 

f^eferrinq  to  theorem  T,  4F1  is  dependent  on  AFla  and 
AF  1 b . 


Theorem  IV.  Table  T,  based  on  n conditions^  con- 

n 

tains  one»  and  only  one,  set  of  2 independent  nure 
functions. 

As  an  illustration  of  theorem  IV»  consider  the  followina 
table. 


AFl 

AF2 

AF3 

AF4 

AF5 

AF6 

AF7 

AF8 

Cl 

Y 

Y 

Y 

Y 

N 

N 

N 

N 

C2 

Y 

Y 

N 

N 

Y 

Y 

N 

N 

C3 

Y 

N 

.Y 

N 

Y 

N 

Y 

N 

kVith  the  total  number  of  cnngitions  eoual  to  3f  the 

3 

total  number  of  pure  AWD  functions  should  be  ? ~ d,  accord- 

ing to  theorem  IV.  As  can  he  seen  above*  no  other  oure  AND 
function,  exists  that  does  not  duplicate  one  of  those  in  the 


table 


a 

C2 

A1 


RL 

Y 


Thp  co'^olex  .'isCi'Siori  rule 
siiTiDle  aecision  ri.iles» 
cure  decision  rules. 


HI 


R2 

iL 

N 


X 


5 


I 

I 
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IV.  PREPiPING  DECISION  lAbLES 
A.  BASIC  techniques 

This  section  oresents  two  methods  fon  the  develooment  of 
decision  tables.  The  classical  techniaue  and  the  progres- 
sive rule  development  techniaue»  both  of  which  follow  the 
formal  preoaration  rules  presented  in  an  earlier  section. 

In  tne  classical  techniaue*  all  oossible  combinations  of 
conditions  are  considered  and  a matrix  is  produced  in  the 
conaition  entry  which  represents  all  possible  simple  rules. 
Next*  the  table  is  simplified  by  repeatedly  comoining 
several  simple  rules  into  a complex  rule*  therebv  producing 
fpwer  rules.  The  process  becomes  almost  mechanical*  how- 
ever* and  it  is  oossible  to  lose  sight  of  the  total  problem 
logic. 

The  other  method*  oy  progressive  rule  development*  is 
based  on  formalized  rules  adapted  from  flowcharting.  The 
logic  of  the  problem  is  considered  step  oy  step  and  tne 
table  prepared  as  the  problem  is  studied.  '■lormallv*  this 
method  is  somewhat  faster  than  the  classical  one.  Because 
the  development  of  the  table  is  in  step  with  the  loaical 

* the  total  Ionic  can  always  be  seen. 


a s 


analysis  of  the  nroblem 


It  s^iould  be  oointed  out  here  that  the  forrr  of  the  deci- 
sion table  should  reflect  its  ultiriate  use.  k'ihen  oreoarinq 
a decision  table  for  creorocessinq,  conoact#  sophisticated 
logic  should  be  reflected  in  the  table.  Alternatively,  if  a 
table  is  to  be  used  purely  for  documentation  purposes,  it 
would  be  best  for  the  table  to  be  laid  out  in  a simple, 
easily  readable  form.  The  fact  that  oversophistication  in 
comp ressinq  logic  and  in  minitnizinq  the  number  of  rules  pro- 
duces a table  which  is  more  difficult  for  the  ultimate  user 
to  understand  should  be  neot  in  mind.  Furthermore,  if  care 
is  not  used,  errors  may  i nadver t ant  1 v be  introducea. 

B.  CL^>SSIC4l  TEtHrjIQUF 

The  classical  technique  emphasizes  the  development  of  a 
matrix  reoresentino  all  the  simple  rules  for  the  given  con- 
ditions. Then  the  full  matrix  will  ce  reduced,  if  oossit'le, 
to  a fewer  number  of  rules  by  combining  the  simple  rules  to 
form  complex  rules.  The  following  seven  steos  may  be  fol- 
lowed almost  mechanically  to  produce  a logically  correct  and 
relatively  concise  table. 


List 

at  1 

Condi t i ons 

List 

al  1 

act  ions 

5.  Complete  condition  entry  (for  full  matrix) 


d.  Complete  action  entry 


5.  Consolidate  ano  form  comolex  rules 


6,  Check  table 

7.  Transcribe  final  version  and  recheck 


This  techniaue  can  be  used  for  all  three  types  of  tables 
(limited/  extended/  and  mixed  entry).  Each  of  the  seven 
steps  will  be  described  in  the  followinq  sub-sections. 

1.  List  Conditions 

By  thoroudh  study  of  the  orobleir  under  considera- 
tion/ all  the  relevant  conditions  may  be  determined  and 
listed.  At  this  ooint/  the  statement  of  the  condition 
should  be  as  clear  and  concise  as  possible.  In  order  to 
avoid  loqically  correct/  but  complicated  statements/  neaa- 
t i ve  expressions  should  be  avoided  whenever  possible.  A 
neqative  statement  relies  on  a aouole  neaative  for  the  posi- 
tive case.  For  example/  the  condition  "no  space  available" 
aives  Y (out  of  space)  and  f'J  (soace  available). 


As  a qeneral  rule/  conditions  which  are  not  indepen- 
dent should  also  be  avoided.  Often/  where  one  condition 
includes  another/  there  may  t>e  some  m.  i sunde  r s t and  i nq  of  the 
problem  at  hand.  Conditions  which  are  not  independent  pro- 
duce imoossiole  rules  and  incomplete  lodic  tables. 


L od i c a I I V / 
does  not  affect 
affect  the  ease  of 


the  seauenc e 
the  validity 
re  a din -3  and 


of  t tie  cond  i t 1 ons 
ot  the  table/  but 
table  construction 


tested 
t does 
The 


US 


basic  quide  to  tollov<  is  to  list  conditions  in  order  of  'rost 
likelv  satisfaction.  <‘«hen  their  relative  likelihood  is  not 
known,  listing  in  the  sequence  in  which  ioentified  is  a aood 
starting  DOint.  It  is  itroerative  to  list  all  possible  condi- 
tions before  oroceedinq  to  the  next  steo. 

i . List  Actions 

Listing  the  actions  next  allows  a douole  check  to 
ensure  that  all  the  conditions  have  been  listed.  Action 
stateTients  are  generally  easier  to  formulate  than  condition 
stat*»<Tients  and  ar“  aener -ally  given  as  sere  sort  of  contr'and. 
hor  convenience,  actions  shoulo  oe  listed  in  the  sequence  in 
whicn  they  are  to  oe  rertorreg.  T r i s rule  is  'ranclatory  wfien 
advanced  techniques,  such  as  recursion  or  table  linkage,  are 
utilized. 

Conclete  Condition  Entry 

At  this  stec,  two  condition  entry  oart  of  the  table 

is  fillea  in.  The  objf^ct  here  is  to  state  all  the  rules 

which  reoresent  all  co^'b  i nat  i ens  of  conditions  with  no 

repetition  or  omission  of  any  combination.  As  previously 

n 

stated,  for  a limited  entry  tahl"  there  are  <?  simple  rules, 
where  n is  the  number  of  conditions. 

At  the  conclusion  of  this  Step,  a ccmpleteo  matrix 
13  formed  in  fho  condition  pntrv  Portion  of  thx«  table  con- 
sisting of  all  the  Possible  simple  rules.  If  the  above 


i 

i 


\ 


1 

1 

I, 


! 

i ' 

I 1 

^ i. 

w 

] 

i' 

! 

1 
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procedure  is  followed,  eac>i  rule  will  be  unique  ana  all 
rules  will  contain  every  combination  of  conditions. 

Comolete  Action  Entry 

At  this  Doint,  each  rule  is  examined.  The  conoition 
entry  is  considered  and  the  aoprooriate  actions  indicated. 
Any  action  required  must  be  consistent  with  any  other  action 
required.  In  the  event-  contradictions  among  actions  can  be 
identifieo  at  this  ooinf,  they  must  be  resolved  by  specify 
ing  an  appropriate  error  action.  Above  all,  it  is  vital  to 
be  consistent  in  handlina  any  ambiguous  combination  of  con- 
ait  i o n s . 

S.  Consolidation 

In  conso I i dat i na  a limited  entry  table,  consider  two 
rules  with  identical  actions  at  a time.  For  each  pair,  the 
two  rules  may  be  consolidated  if  all  the  condition  values 
are  the  same  exceot  one  oair.  For  the  condition  with  the 
unmatched  oair,  a dash  is  entered.  This  one  complex  rule 
then  replaces  the  two  simple  rules.  Continuing  in  this 
manner  will  result  in  a smaller,  more  manageable  table. 

o . Check  Tan  1 e 

At  each  of  the  stages  previously  described,  the  work 
done  on  t^e  table  should  be  checked.  The  earlier  an  error 
is  detected,  the  easier  it  is  to  rectify.  The  checks  that 


U7 


W 


I 

I 


should  h>e  arpliea  fall  into  two  broad  cateqories;  checking 
for  content  and  checkina  for  structure. 

Check! no  the  content  should  ensure  that  the  action 
entries  associated  with  each  simple  rule  on  the  unconsoli- 
dated table  are  correct.  Checking  the  structure  of  the 
final  table  is  an  attemot  to  ensure  that  the  table  contains 
no  con t r ad i c t i ons  or  redundanc i es . 

7,  "^ake  Final  Version 

Once  a table  has  been  checked/  it  may  be  necessary 
to  transcrioe  it  to  oroduce  a final  version  which  can  then 
be  used.  The  condition  and  action  stuns  should  be  checked 
to  make  sure  that  they  are  clear. 


Normal  1 

v / the 

condi t i ons 

are  listed 

so 

that 

those 

with  the  most 

"don  ' t 

care"  entri 

es  are  at 

the 

bottom 

o f 

the 

list.  Similarl 

y / the 

senuenc  e o f 

rules  can 

be 

a 1 t e r ed 

so 

that  those  rules  containina  the  most  "don't  care"  entries 
aooear  first.  Larae  tables  may  be  divided  into  smaller  cor- 
tions  for  checking. 

C.  PROGRF.SSIVE  RULE  DEVELOPMENT  TECHNIQUE 

Progressive  rule  oevelooment  is  based  on  standard  tech- 
nigues  for  or^oarino  flowcharts.  .'Vhereas  the  classical 
technicue  reqtjires  tnat  all  possible  combinations  of  condi- 
tions oe  defined/  progressive  rule  developm/»nt  reguires  that 
conditions  be  written  on  the  table  as  they  are 


li 

n 


I 


9 

I 


i den  r i f I ed 


Each  rule# 

including  the 

action  entry# 

is  entered 

as 

the 

orob 1 em  is 

ana  1 vzed . 

The  procedure  for  progressive  rule 

deve 1 opment 

as 

p r o- 

rosed  by 

London  (11? 

i s enume ra t ed 

below.  Note 

that 

t he 

steps  are 

repeat  ed  until 

the  complete 

table  has  been 

f o r med . 

•Shen  all  Dossihle  conditions  have  been  considered#  the 
table  shoula  be  checked  for  contradictions  and  redundancies. 
The  foMowinq  sub-sections  point  out  the  major  points  to  be 
k»*rt  in  T'inn  at  every  step. 

1.  Consider  a Condition 

At  tnis  Point#  a condition  should  be  clearly  entered 
into  the  condition  stub.  As  a starting  point#  enter  a Y 
(true)  response  in  the  conoition  entry  adjacent  to  the  con- 
dition. 

2,  Consiaer  Further  Conditions 

Determine  what  other  conditions  are  necessary  before 
action  can  be  taken.  They  must  also  be  entered  in  the  table 
as  in  step  I.  Tne  action  portion  of  the  table  may  then  be 
completed  for  this  newly  formed  rule. 

5,  Form  f'ext  Rule 

The  next  rule  may  be  formed  by  transcribing  the  pre- 
vious rule#  changing  the  last  condition  entry  for  which  all 
values  have  not  been  considered.  For  example#  the  last  Y 
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value  entererl  should  he  chanaea  to  an  N.  All  values  above 
the  changed  value  are  keot  the  saire. 

0.  an  examplf 

This  section  oresents  a solution  to  the  following  samole 
problerr  usina  the  classical  technioue. 

Hirina  a Receptionist 

A new  receptionist  is  needed  for  an  insurance 
co'rpanv.  She  -nust  be  able  to  type  at  least  bO 
words  per  minute  and  take  dictation  at  a minimum 
of  RiT  words  per  minute.  All  applicants  should 
be  willing  to  work  for  a salary  not  greater  than 
$5500  a year.  All  applicants  who  meet  typing 
reouirements  but  not  the  aictation  reouirements 
will  be  referrpc  to  the  typing  pool. 


The  first  step  is  to  identify  the  conditions  that  must 
be  met.  They  are  then  placed  in  the  congition  stub  of  the 
decision  looic  table  in  some  order  of  precedence  (see  Table 
b).  All  oossible  actions  should  be  placed  in  the  action 
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stub 


next 


R1 

R2 

R3 

R4 

R5 

R6 

Y 

Y 

Y 

Y 

N 

N 

Y 

Y 

N 

N 

Y 

Y 

Y 

N 

Y 

N 

Y 

N 

R8 


.N 


N 


N 


TYPE  ^ 60  WPM 


SALARY^  #5500 


SHORTHAND  ^90 


HIRE 


DO  NOT  HIRE 


REFER  TO 
TYPING  POOL 


fABLL  D.  Hirinq  a Keceotionist 

The  nurrber  o*  rules  renuireq  to  corsider  all  oossible 
combinations  oT  ccnoitions  is: 


X 

X 

X 

X 

Numoer  of  rules  = 2. 

where  n = the  niimber  of  conditions 
In  this  case*  ^ rules  are  required*  as  indicated  in  Table  b. 
l^ote*  however*  that  rules  S thru  may  be  concined  due  to 
the  fact  that  failing  the  tvoinq  condition  results  in  the 
action  "Do  fxiot  hire"  in  all  cases.  Thus*  it  can  be  seen 
that  the  table  may  be  dramatically  simolifieo  immediately. 

Further,  the  fable  may  be  reduced  to  the  one  deoicted  in 
Table  7 t;y  notino  the  fact  that  ubon  satisfying  condition  t 
but  failure  of  conriiricn  2 , an  ability  to  t axe  shorthand  at 
a rate  of  'lO  or  more  words  rer  minute*  results  in  that 


aoDlicant  beinq  refereb  to  the  typinq  poo).  Note  that  rear- 
ranging conOitions  in  order  of  least  number  of  aon ' t care 
entries  results  in  the  final#  bifurcated  form  shown.  That 
is#  it  is  arranged  whereby  each  condition  has  its  Y answers 
grouped  together  and  its  M answers  grouped  together  to  form 
oaths. 


R1 

R2 

R3 

R4 

TYPE>60  WPM 

Y 

Y 

Y 

N 

SHORTHAND^>90 

Y 

Y 

N 

— 

SALARY  5 $5500 

Y 

N 

— 

— 

HIRE 

X 

DO  NOT  HIRE 

X 

X 

REFER  TO 
TYPING  POOL 

X 

TABLE  b.  Hiring  a Receptionist  - Rinal  Solution 


V 


PREPROCESSOR  DESCRIPTION 


A.  THE  ALGORITHM 

There  were  a 'nultitude  of  different^  soir'etitres  oprosinq/ 
aftributes  that  the  desired  aiaorithm  was  to  possess.  These 
ranged  from  the  traditional  considerations  of  output  module 
size  and  execution  soeed  to  restrictions  arising  from  the 
intended  i mo ) ement at i on  computer  facility. 

The  choice  of  compiler,  interpreter,  or  oreprocessor  was 
resolved  in  f a \/ or  of  the  oneorocessor  due  to  the  considera- 
tions dictated  by  the  aene r a 1 -pu roose . multi-user.  interac- 
tive operating  system.  U^'lIX  [71.  as  implemented  at  the  fjaval 
Postgraduate  School,  and  its  support  of  the  orogramminq 
languaoe  C [2SJ.  Precarinn  either  a compiler  or  interpreter 
would  have  entailed  duplication  of  that  support  to  some 
degree. 

Algorithms  have  been  developed  to  attempt  to  minimize 
execution  time.  execution  module  size,  or  both  [19J.  The 
minimization  effort  arose  from  the  consideration  that  the 
prepared  execution  module  was  to  be  usee  repeatedly,  with 
the  preprocessor  itself  being  us<»a  relatively  infreouently 
on  individual  tables.  However,  in  the  academic  situation, 
the  emphasis  has  been  placed  on  preparing  a working  module 
rather  than  preparing  a production  type  module.  This 


S5 


indicates  that  the  o renrocessor  itself  will  be 


used 


rather 


freauently  and  the  output  trodule  will  be  used  very  seldo'n. 
This  led  to  the  realization  that  the  preprocessor  size  and 
execution  time  were  of  nreater  importance  than  output  module 
size  and  execution  ti""e.  It  was  therefore  considered  desir- 
able for  the  preprocessor  code  to  be  small  in  size  and  Quick 
in  execution.  Further,  the  data  area  of  individual  users 
was  to  be  relatively  small  yet  still  capable  of  handling 
more  than  ten  to  twelve  conditions  in  the  decision  loqic 
table. 


The  final  attribute  of  major  importance  was  that  the 
algorithm  be  capable  of  beina  implemented  with  a minimum  of 
user  skill.  It  was  felt  that  several  soph i s t i c a t ed  algo- 
rithm, s [18,^3,28,2^11,  while  of  major  importance  in  both  the 
academic  and  industrial  communities,  demanded  too  much  user 
input  to  be  desirable  f^r  beainning  necision  logic  transla- 
tor users. 


The  various  network  algorithms  dcjcribeo  (18,1'5,?8,101 
were  eliminated  as  a class  since  the  data  area  available  in 
our  mini-computer  was  insufficient  for  ten  to  twelve  condi- 
tions and  the  preprocessor  execution  time  was  estimated  to 
be  excessive. 


Rule  mask  alaorirhms  nav®  been  shown  to 
cient  with  resoect  to  storage  reouirements 
size)  (I'^l,  translator  size,  and  execution 
with  respect  to  execution  module  run 


be  highly  effi” 
(execution  module 
time,  but  poor 
time  since  each 


condi^ion  had  to  be  tested  to  prepare  the  mask  and  then  this 


mas<  cotroared  with  all  the  rule  masks.  This  objection  faded 
when  it  was  recoonizeo  thar  the  target  user  group  would#  in 
general#  be  but  slightly  concerned  with  performing  the  sta- 
tistical background  work  necessary  to  provide  the  input  data 
to  obtain  truly  optimal  execution  time  code. 

The  rule  mask  tecbnioue  of  Press  (201  has  been  shown  to 
be  very  good  with  rescect  to  execution  m.odule  run  time  (IP]. 
Additionally#  the  target  user  grouo  was  expected  to  be  capa- 
ble ot  orogrammino  decision  looic  tables  using  the  input 
regui  red  by  this  algorithn"  with  relative  ease. 

Por  these  reasons#  the  choice  of  an  algorithm  was  that 
of  Press  This  algorithm  built  a rule  mask  for  each 
rule.  Code  was  generated  to  seauentially  evaluate  each  con- 
dition ana  construct  a test  mask  from  the  results.  The  rule 
masks  were  then  scanned  to  find  one  that  matched  this  test 
mask. 

This  aloorithm,  on  one  hand#  Hid  not  reouire  a large 
data  area#  which  would  have  been  the  case  with  a network 
algorithm.  Yet#  on  the  other  hand#  the  programmer  was  given 
nothing  to  control  execution  time  of  the  output  proaram 
other  than  simply  placing  the  rules  in  decreasing  order  of 
expected  freauencv  of  satisfaction. 

In  order  to  provide  a smaller  oreorocessor  module  to 
document  the  grammar  of  the  decision  logic  table#  and  to 


simplify  any  future  changes  to  that  qrammarf 
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compiler-compiler  Oevelooecl  hy  Bell  Laboratories  (6)  » was 
used  in  the  construction  of  DELTRANS*  the  decision  logic 
translator  proposed  here. 

B.  GENERAL  ORERAriON 

As  previously  stated^  DFLTRANS  was  designed  to  be  a 
sequential  testing  rule  masi  decision  loaic  table  transla- 
tor. This  meant  that  for  each  derision  logic  table  OELTRANS 
was  to  preoare  a rule  mask  to  match  each  rule»  generate  cone 
to  test  each  condition  sequentially  and  set  a test  mask,  and 
finally  generate  code  to  test  the  test  mask  aoainst  the  rule 
masks,  searcoinq  for  a match. 

To  accomplish  the  enumerated  tasks  OELTRANS  was  con- 
ceived to  ooerate  in  five  distinct  out  interdependent 
phases.  The  five  phases  were  designated  copy,  data  area 
initialization,  data  input,  computation,  and  finally  code 
generation.  iVhem  more  than  one  t ao  1 e was  to  be  preprocesseo, 
DELTRAI'JS  returned  to  the  cocv  phase. 

As  designed,  DELTRAIJS  beaan  execution  in  the  copy 
phase.  Code  was  merely  transferred  from  the  input  to  the 
output  file,  removing  comments  while  searching  for  the 
first  un  arrow  (tl  not  within  quotes,  which  indicated  the 
start  of  a decision  logic  table. 


So 


At  this  ooint  DELTRANS  entered  the  data  area  initializa- 


tion phase.  In  this  phase#  OELTRA^iS  read  a list  user 
options  such  as  the  number  of  actions  ^or  conditions#  and 
initialized  the  internal  structures  in  preparation  for  table 
input.  The  user  was  provided  with  a qreat  deal  of  flexibil- 
ity in  both  size  and  format#  and  considerable  error  checking 
was  performed  during  this  Phase. 


If  all  initialization  input  was  in  order#  the  preproces- 
sor proceeded  to  the  third  chase#  data  input.  In  this 
phase#  tne  table  was  read  and  its  contents  sorted  and  stored 
for  the  next  phases.  Once  aoain,  extensive  error  checking 
was  done  during  this  chase. 


when  the  final  up  arrow  in  a table  was  read  and  the  data 
incut  phase  complete#  DELTRANS  shifted  into  the  computation 
phase.  In  this  chase  there  were  two  major  events#  amciguitv 
and  completeness  checkino  and  the  construction  of  the  indi- 
vidual rule  masks. 


The  final  chase  of  code  aeneration  was  the  point  of  gen- 
eration of  both  the  output  code  and  a formatted  decision 
logic  table  for  use  in  dehuocjinq.  DFLTRANS  returned  to  the 
copy  Phase  to  pass  on  any  additional  code  or  prepare  for  a 
f o 1 1 ow i no  table. 


All  l)ut  the  final  phase  of  the  preprocessing  rould  cause 
fatal  errors.  If  an  unexpected  end-of-file  was  encountered# 


an  error  messaoe  resulted  and  the  outout  buffers  were 


flushed  into  the  output  file.  Otherwise*  the  stanOard 
recovery  technioue  was  to  search  for  the  up  arrow*  which  was 
assumed  to  mark  the  end  of  the  current  table*  and  then 
restart  from  the  copy  phase. 

C.  AMBIGUITY  AND  C OMPLE  T E f'E  SS  CHECKING 

OELTKAMS  was  desianed  to  perform  two  distinct  types  of 
table  loaic  checking  for  the  user*  but  had  no  capability  of 
correcting  any  errors  exposed  during  this  logic  checkinq. 
Completeness  checkinq  was  attempted  only  after  the  ambiguity 
checking  was  completed  and  no  errors  found. 

Ambiquitv  checkinq,  as  Performed  by  DELTRANS,  was  based 
on  two  fundamental  requirements  for  all  decision  Icqic 
tables  CIP].  First*  every  rule  must  have  at  least  one  asso” 
ciated  action.  Ann  second*  each  distinct  combination  of 
trutK  values  for  the  oiven  set  of  conditions  must  satisfy 
exactly  one  rule. 

The  first  requirement  arises  because  for  every  set  of 
conditions  some  action  is,  in  fact*  intended  or  should  be. 
Whether  that  action  oe  return  to  the  callinq  point  in  the 
program,  halt  proqram  execution  immediately*  or  enter  an 
infinite  no-ooeration  loop*  some  program  action  is  intended. 

ChecKinq  for  redunlancy  and  inconsistency  in  table  con- 
struction has  Peen  implementen  bv  comparing  the  rules  to 
insure  that  t'etween  each  pair  of  rules  there  exists  at  least 
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J Inconsistency  Fxample 

' Ionic  table  was  ncn-anbiauous 
ternine  i ■*  that  table  was  con- 


nn  an 

amh i quous 

tab! 

e i s 

nn  r e d » 

^^0  1 1 ac  k 1 

H 1 c ks  » 

and 

»ac  h 

decision  1 

oa  i c 

table 

,Q 
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r 

I 

1 

contains  2 indeoen'jent  sifTple  nj1es»  where  n is  the 

of  conditions.  They  have  also  oroven  that  alt 
n 

represent  2 sifrote  rules»  where  n is  the  nurrher  of 
cares"  in  that  rule.  OtLTRA^iS  has  incorporated  these  two 
theorems  in  its  completeness  testino. 

If  a decision  locic  table  contains  two  or  more  dependent 

I 

rules  it  is  said  to  be  amhinuous.  In  that  case  the  two 
theorems  on  completeness  would  not  acolv.  Therefore  the 
ambiouity  cneckinq  was  desinned  to  nreceen  tne  completeness 
c hec  k i nq . 

A hen  ctieckina  for  completeress»  toe  preprocessor  was 
oesianed  to  scan  each  rule  for  a count  of  toe  "aon't”  car*»" 

I 

entries  in  that  rule.  for  each  rul-^*  2 was  raised  to  toe 
power  of  this  count  and  the  resultinn  value  added  to  a tally 


sum 

for  the  entire  tafle.  a hen 

al  1 

rules  *'ad 

been 

scanned. 

this 

fall 

y was  comcared  with 

value  of  2 

r a i 

sea  to  the 

numbe  r of 

conditions.  If  these 

two 

were  eaual 

the 

table  was 

comp 

1 et  e ; 

Otherwise  the  table  was  i 

nc omp 1 e t e . 

If  an 

input  decision  loaic 

t ab  1 

e was  found 

t o 

be  com- 

L plete»  the  else/error  rule  can  never  be  satisfied  and  is 

therefore  superfluous.  Since,  hv  design,  DfLTRAf;S  required 
an  else/error  artinn,  it  was  necessary  to  provide  the  oro- 
qrammer  with  the  caparilitv  to  input  a null  action  foot  a 
no“OOeration)  to  be  used  with  comnlet®  tables. 





numbe  r 
rules 
"don  ' t 


If  the  count  of  simcJe  rulps  in  a decision  logic  table 
revealed  that  not  all  possible  rules  had  been  enunerated, 


the  else/error  action  was  examined.  Ifthat  action  was  a I 

I 

null  action/  then  DELTRANS  was  designed  to  output  a warning 
messaae  indicating  that  an  incomplete  table  had  been  encoun-  i 

tered.  Of  course/  if  the  program  had  specified  a valid 
else/error  action  then  the  decision  logic  table  iS/  by 
default/  complete. 


CON'CLUSIONS  AMD  PECON*’^ENDA  T I ONS 


V I . 

A.  CONCLUSIOMS 

Throughout  the  available  literaturcf  decision  logic 
table  structure  and  teririnology  was  found  to  be  rather 
straightforward  and  s t anda rd i zeo » as  oresentea  here.  This 
has  facilitated  the  programmer ' s use  and  understanding  of 
aecision  looic  tables. 

The  theory  uDcn  which  decision  logic  table  construction 
and  translation  has  been  based  was  found  to  vary  between 
extremes.  Pollack  ana-  others  [18]  have  presented  clear  and 
! direct  foundations  forconstruction  and  translation.  Some 

algorithms  were  oiscovered  which  were  based  more  on  intui- 
tion than  theory  (PP],  while  others  were  founcea  in  theory 
so  complex  that  programmers  haye  had  difficulty  in  grasping 
the  logic  of  a given  problem  [a, 22, 2^1. 

j The  advantages  that  decision  logic  tables  offer  have 

shown  that  every  pro c? rammer  should  at  least  be  introauced  to 
-decision  logic  tables  and  thus  be  able  to  use  this  powerful 
tool. 

Oecision  Ionic  tables  can  ne  a powerful  aio  in  effectiye 
' communicating,  both  man-to-man  and  ma n - t o-mac h i ne , in  pro- 
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gramming,  and  in  Oocumentinn 


The  format  of  decision  logic 


tables  oermits  oraanization  and  concise  visual  presentation 


ot  complex  logic.  Decision  looic  tables  also  provide  the 
programmer  with  a very  effective  tool  for  insuring  that  the 
program  logic  is  noth  correct  and  complete^  items  that  other 
methods  tend  to  obscure. 

Add i t i ona 1 1 y » since  decision  logic  tables  are  both  easy 

to  construct  and  modify,  and  may  Oe  used  as  computer  input. 

/ 

decision  looic  tables.  when  properly  used.  can  be  an 
extremely  effective  tool  for  communicating,  programming,  and 
document i ng . 

Of  the  many  decision  logic  table  translators  avail- 
abieCl^l.  DELTRA^S.  as  orooosed  here,  was  the  only  known 
available  translator  designed  for  implementation  on  the  UNIX 
timesharing  system  for  the  C programming  language. 


The  ultimate  value  of  OfLTPAi'jS  lies  in  its  versatility 
of  application  throughout  manaoement.  scientific.  and 
engineering  fields.  Decision  logic  tables  themselves  pro* 
vide  a simple  metnoo  for  recording  logic  so  that  all  ele- 
ments of  a decision  are  precisely  defined.  Tables  make  it 
possible  for  managers,  scientists,  and  engineers  to  use  com- 
puters directly.  ituch  subseouent  programming  ang  cooing  may 
be  eliminated. 


DELTKANS.  as  devnloped.  fills  that  oao  netween  a C pro- 
grammer with  decision  tables  and  the  C language  compiler. 
The  daval  Postgraduate  School  has  been  orovided  with  a tool 


n3 


for  use 


in  introducinq  students  to  the  use  of  decision  logic 
tables.  A tool  that  until  now  has  not  been  available. 

H.  RECU^'N’FNOAT  IONS 

Several  refinetrents  to  DFl.TRANS  have  been  suggested  to 
further  enhance  its  utility.  Prior  to  enurrerating  the  most 
imoortant  of  these  refinements  it  should  be  pointed  out  that 
each  of  these  requirements  conflicts  with  some  of  the  design 
criteria  used  in  constructing  OELTPANS. 

Adaitional  completeness  testing  and  error  checking  caoa- 
bilities  would  assist  the  orogrammer  with  complex  loaic.  If 
the  necessary  space  and  time  were  deemed  acp r oo r i a t e » the 
preprocessor  could  be  so  modified  to  take  full  advantage  of 
the  implicit  entries  during  completeness  checking.  Further 
coding  could  provide  for  automatic  error  correction  of  a 
numner  of  orooramminq  errors^  for  example  combining  redum- 
dant  rules. 

An  alternate  conversion  algorithm  could  he  implemented. 
By  using  one  of  the  network  algorithms  that  has  been  proven 
to  provide  minimum  execution  time  output/  the  capabilities 
of  OELTWAMS  would  be  enhanced.  Since  the  data  structures 
for  holding  the  actions/  congitions/  and  rules  and  for  link- 
ing the  rules  to  the  actions  were  built  and  maintained  by 
UELIRAfiS/  the  implementation  of  an  additional  coding  algo- 
rithm would  be  simplified.  However/  these  algorithms  would 
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require  additional  proqrammer  input  and  additional  time  and 


space  for  the  preprocessor. 


If  deemed  appropriate/  the  required  increase  in  size  and 
decrease  in  soeed  in  the  preprocessor  could  be  accepted  and 
DELTRANS  could  be  modified  to  accent  extended  and/or  mixed 
entry  conditions. 


A conversational  translator  could  be  developed  using 
DELIKANS  as  a base.  This  would  greatly  reduce  the  file 
manipulating  reauired  of  the  proorammer  under  DELTRANS. 


A final  r ec ommenda t i on  is  that  decision  logic  tables  be 
crespnted  to  students  as  a cart  of  an  introductory  computer 
science  course.  Even  if  taoles  rust  be  hand  translated/ 
decision  Ionic  tables  can  provide  great  assistance  to  the 


programmer/  whether  he  be  a beginner  or  experienced. 
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Effective  Use  of  OELTRAi'jS 

DELTRANS  is  Uesiqned  to  be  utilized  by  those  fluent  in 
the  (lesion  an(j  construction  of  decision  loqic  tables.  Those 
without  such  a background  are  directed  to  the  aoprooriate 
sections  of  the  oarent  thesis  itself  and  Solorron  Pollack's 
wo  r K Decision  Tables:  Theory  and  P r a r t ice  [1^1  for  an  intro- 
duction to  decision  loaic  tables. 

Additionally*  so(re  basic  familiarity  with  the  UNIX 
or>eratin(3  system  is  assumed;  specifically*  using  the  edi- 
tor* proaramming  in  C*  and  file  manipulation.  The  caper 
"UNIX  for  Beginners"  by  hernighan  [7]  is  an  excellent  start- 
i nq  point. 

Only  with  a thorough  oraso  of  the  concepts  of  both 
decision  tables  and  UiJIX  may  a user  cf  DELTRANS  reap  its 
intended  benefits  as  described  herein. 
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I.  INTRODUCTION 


Decision  loQic  tables  describe  decision  rules.  A deci- 
sion rule  consists  of  a set  of  conditions  plus  a set  of 
actions.  The  relationshio  between  conditions  and  actions  is 
of  tne  IF-THEN  type.  More  snec  i f i c a 1 1 y » if  the  given  condi- 
tions are  met,  tnen  the  corresponding  actions  are  taken. 


DELTRAfiS  allows  C programmers  to  convert  a 
containing  one  or  more  decision  loaic  tables  into 
program  ready  for  compilation. 


C program 
a C source 


The  user  needs  only  a basic  knowledoe  of  the  C language 
in  order  to  use  OELTRA^jS.  The  decision  table  input,  nested 
witRin  a C program,  must  conform  to  the  specifications  of  a 
C-oriented  decision  table  language  presented  in  section  II 
of  this  manual.  The  language  descrioed  combines  decision 
table  capabilities  witR  many  of  the  features  of  C. 


DELTRANS  processes  one  decision  table  at  a time.  It 
reads,  decodes,  and  edits  each  line  of  the  table.  Messages 
are  printed  on  the  terminal  when  errors  are  detected.  The 
decision  table  is  outout  as  C source  code  on  a specified 
file.  Optionally,  a formatted  listing  may  be  obtained. 
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The  dec  i 

s i on 

loaic  translator  is  designed 

for 

use 

on 

the 

POP-I  1 

with 

the  UNIX  operating  system  and 

6UK 

bytes 

o f 

user 

program 

s t or aoe . 

A.  PURPOSE 

The  purpo'^-'  oT  OELTRANS  is  to  provide  an  alternative  to 
the  C proqrarri<rer  when  faced  with  a coirple*  logical  situa- 
tion. The  preprocessor  is  designed  to  be  convenient  for 
oreparinq  C program. s containing  decision  logic  tables  at  a 
remote  terTiinal.  A cecision  looic  table  mav  Ee  included 
within  any  C orooran,  alonq  with  anv  S v n t ac t i c a 1 1 y correct  C 
express  ions. 

b.  FU^CTI0^3  PERFCR^^’FD 

Briefly*  OELTRA'iS  ooens  and  reads  from  the  input  file 
specified  nv  the  user  and  oreorocesses  the  C program  con- 
tained therein.  The  Default  is  input  from  the  terminal 
itself.  Source  code  is  placed  on  the  output  file  also 
specified  by  the  user.  Its  default  name  is  'd.tab.c*.  This 
file  is  initially  opened  and  then  closed»  along  with  the 
input  file»  when  preprocessing  is  complete.  Each  decision 
loaic  table  is  coded  as  a seoarat®  subroutine  in  this  file. 

Optionally/  a formatted  and  thus  very  readable  corv  of 
each  decision  table  contained  in  the  input  file  may  be 
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redirectea  to  the  line  orinter  or  any  other  file  upon  com- 
pletion of  D r eo roc e s s i nq . 

Additionally,  the  decision  looic  table  is  examined  for 
ambiquous  or  incomplete  loqic. 

C.  LIMITATIONS 

The  orocessor  limitations  described  here  are  due  to  the 
dimensions  of  various  arrays  internal  to  the  p r eo r oc esso r . 
Most  of  these  limitations  may  be  relaxed  by  minor  altera- 
tions to  the  oreorocessor ; a consultant  may  be  of  some 
assistance  in  this  enoeavor. 

Toe  following  list  of  maximum  values  must  be  strictly 
adhered  to  avoid  processtno  errors. 

Maximum  number  of  conditions  = lo 

Maximum  numt)er  of  actions  = 5^ 

Maximum  number  of  rules  = 

Maximum  stub  length  = 31  characters 

Additionally,  the  name  of  the  table  subroutine  may  tie  no 
more  than  8 characters. 

The  oreorocessor  was  written  usinrj  a rule  mask  scanning 
techniaue.  A fundamental  assumption  renuired  when  using 
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this  techniaue  is  that  every  condition  is  tested  when 
preparing  a mask  which  is»  in  turn»  used  to  scan  for  the 
proper  rule.  This  fact  forces  the  programming  limitation 
that  each  condition  return  a valid  test  regardless  of  the 
results  of  previous  tests.  Note  that  the  conditions  are 
tested  sequent i a 1 I V f first  to  last. 

Note  especially  the  reserved  woros  dda»  ddb»  and  ddc . 
These  may  not  be  used  in  the  logic  in  decision  logic  tables 
since  the  creprocessor  uses  these  as  names  for  the  masks. 

Finally,  the  up  arrow,  except  when  inside  Quotes  (sinale 
or  double)  will  be  read  as  a definite  signal  to  tne 
preprocessor. . .beware! 

D.  additional  RACkGRCUNO 

The  preprocessor  was  written  durino  January  ana  Febru- 
ary, 1077,  as  a thesis  project  by  Lt.  J.F.  Keller  and  Capt  . 
R . . Roe  sc  h. 

Subroutines  reauired  by  the  system  are  as  follows: 

getc  putc  fopen  orintf 

exit  fflusr  fcreat 

The  VACC  library  routines  are  also  required. 
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II.  GENERAL  INFORMATION 
A.  ACCEPTABLE  INPUT 

A decision  loqic  table  n>av  occur  anywhere  within  a C 
program;  however,  it  is  normally  considered  as  a procedure 
and  should  be  treated  accordingly.  As  shown  in  Figure  1, 
the  table  itself  is  first  recognized  by  the  preprocessor  by 
the  occurrence  of  a left  arrow  ('♦-')  as  the  first  character 
of  any  line  within  a C program. 

The  table  itself  is  divided  into  three  distinct  sec- 
tions, separated  by  the  up  arrow  ('T'),  as  depicted  in  Fig- 
ure 1.  As  shown,  the  sections  are  identified  as  the  option 
section,  the  condition  section,  and  the  action  section. 

♦- 

OPTION  SECTION 

T 

CONDITION  SEC  I ION 

T 

ACTION  SECTION 


PI  1.5 UR E 1.  Decision  Table  Format 
7 5 
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( ) 

( 
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i nt 

k ; 

7 

for 

( k = 0 ; k < 6 

k + t)  ( 

8 DrintfC'SnThe  numters  to  test  are  ;\n"); 

9 orintf("\tP  = %d\n\tS  = Xd\n " , r ( k 1 , s I k J ) ; 

10  printf("\tT  = %a\n",tn<]); 

11  1 oat  ab ( k ) ; 

12  } 

13  1 

1'4 

1 5 rpos  ( ) ( 

16  printf("R  is  cositive.\n"); 

17  > 

18 

19  e 

20nloatab(c)  into#  < 

21  //  this  is  a comment 

22  r S c 5 

23  a a 
2 ^ e 1* 

25  d i n t a ; 

26  c h a p b ; 

27  T 
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Proqra'p  with  a Decision  Loqic  Table 
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Each  section  has  a soecific  format  and  although  there  is 
much  freedom  of  input  allowed#  several  rules  must  be  fol” 
lowed  as  described  in  the  followina  sub-sections. 


1.  The  Ootion  Section 

The  format  of  the  option  section  is  relatively  free# 
however  several  items  must  appear  and  be  initi^li^ed.  Docu- 
mentina  comments  follow  the  rules  of  C and  thus  may  appear 
anywhere  within  this  section.  In  accordance  with  those 
rules#  they  must  be  oreceeded  by  a double  slash  ('//'I  or 
preceened  by  '/*'  and  followed  by 

Tne  possible  ootfons  are  listen  belo». 


1 . 

' a ' 

or  ' 

A ' 

n u D r 

of  actions  ; 

reau i red 

?. 

'c  ' 

o r ' 

C ' 

number 

of  conditions  : 

r enu i red 

3. 

'd' 

o r ' 

D • 

dec  1 arat i ons  : 

OP  t i ona 1 -see 

below 

a. 

•e* 

or  ' 

E ' 

else  / 

error  action  ; 

r eou i red 

5. 

•n  ' 

o r ' 

N ' 

subroutine  name  J 

reau i rea 

b . 

' r ' 

or  • 

R ' 

numbe  r 

o f ru 1 es  : 

reau i r ed 

I f 

the 

dec laration  not 

ion  ( ' d ' or  ' Q ' 

) i s used  in  a 

table, 

1 t 

must 

be 

the 

last  option  used  in  the 

opt  ion  section 

of  that 

t ac 1 e . 

A 1 

1 

V a r i ab 1 e s 

local  to  the 

decision  table 

itself  must  he  declared  to  avoin  future  compilation  errors. 
As  Shown  in  Figure  £#  the  declarations  must  re  syntactically 
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I 


correct  C declarations.  DELTPANS  implements  this  feature  by 
passinq  untouched  to  the  output  file  all  code  between  the 
'd'  (or  'D')  and  the  up  arrow  at  the  end  of  the  option  sec- 
tion. 

Additionally*  the  followinq  options  must  be  speci- 
fied in  the  format  indicated: 

a.  The  number  of  conaitions: 

C <number>  or  C <number> 

b.  The  numper  of  rules: 

r <number>  or  R <number> 

c.  The  number  of  actions: 

a <number>  or  A <number> 

Again,  as  shown  in  Ficure  these  ootions  may  be  specified 
in  free  form  w i t r one  or  -ore  soaces  between  a letter  and  a 
number  . 

Another  required  ootion  is  the  name  or  'n'  option. 
It  must  also  aooear  before  the  declarations  and  must  be  of 
the  fgllowina  format: 

n <name>  (<form3l  parameters^)  <tyre  specifications>  } { 

where 
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' n ' may  be  ' N ' . 

<na(ne>  fray  be  from  1 to  characters 

<formal  carameters>  is  optional  depenOinq  upon 
required  parameters. 

<tyoe  spec i f i cat i ons>  are  required  for  all  parame- 
t e r s dec  1 a red , 

For  examolef  line  ^0  in  Figure  2 names  the  output 
subroutine  "logtab"  with  one  parameter*  "c".  Compare  with 
the  output  code  in  Figure  'J. 

Tne  final  required  entry  in  the  option  section  is 
the  else/error  action.  The  preprocessor  will  physically 
code  this  as  the  final  "else"  action  is  the  output  code. 
Tne  format  of  the  else/error  is  an  'e'  (or  'E')  followed  by 
any  number  (including  zero)  of  blanks  and  tabs  followed  by  a 
string  of  at  most  31  characters  followed  by  ' iT ' . The  31 

characters  must  form  a valid  C expression  or  qrouo  of 
expressions. 

2.  The  Condition  Section 

The  condition  section  is  organized  as  a series  of 
condition  lines  with  the  end  of  the  section  indicated  by  an 
UP  arrow. 

Each  condition  line  contains  four  entries:  a condi- 

tion stub  of  UP  to  31  characters*  an  at  sion  ('.i)')*  which 
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indicates  the  end  of  the  condition  stub;  an  optional  list  of 
truth  values  cor resoondi nq  to  numbered  rules;  and  finally  a 
semicolon*  which  indicates  the  end  of  the  condition  line. 

The  condition  stub  is  cooied  character  for  character 
(maximum  31)»  up  to  the  at  sign,  directly  into  the  appropri- 
ate internal  structure. 

The  format  for  the  list  of  truth  values  is  rela- 
tively free-form  in  that  tabs,  spaces,  and  newlines  are 
ignored  when  appropriate.  The  default  entry  for  each  rule 
is  a "don't  care"  or  aash.  To  overwrite  with  any  logic 
letter  (Y,y,N,n,»,S,-),  that  logic  letter  is  placed  in  front 
of  a set  of  Parentheses  containing  the  list  of  rules  for 
which  tnat  looic  letter  is  to  be  entered. 

This  list  of  rule  numoers  must  contain  at  least  cne 
rule  number  and  mav  be  in  either  or  both  of  two  formats. 
Ihe  first  format  is  a list  of  single  rule  numbers,  separatee) 
by  commas,  in  any  aesired  order.  The  second  or  "through" 
format  uses  one  rejle  number,  a dash,  and  then  another  rule 
number.  The  effect  cf  this  format  is  to  enter  the  selected 
logic  letter  into  each  rule  starting  with  the  first  and 
including  all  the  rules  through  the  last.  See  Figure  ? 
lines  2H-31  for  examples  of  condition  lines. 

1‘Jhen  all  the  logic  letter  overlays  have  been 
a semicolon  is  entered  to  alert  DELTRANS  that  the 
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end  of  the  truth  values  for  the  current  condition  has  been 
found  and  that  the  preprocessor  must  proceed  to  either 
accept  the  next  condition  stub»  ort  if  the  up  arrow  is  found 
nextf  proceed  to  decooe  the  action  section. 


DELTPAfjS  was  constructed  with  the  intention  that  it 
be  useo  as  a basis  for  additional  work  in  providing  decision 
logic  table  processing  capability.  The  original  implementa- 
tion does  not  use  the  implicit  entries  ('*'  and  '$')  in 
either  corrr  1 et  eness  testinq  or  in  construction  of  the  output 
code.  Tne  programmer  is  nonetheless  strongly  encouraoed  to 
use  these  entries  since  they  helc  to  bring  out  the  logic  of 
the  problem  at  hand. 

5.  The  Action  Section 


The  action  section  is  organized  as  a series  of 
"action  lines"  with  the  eno  of  the  section  indicated  by  a 
left  arrow.  The  left  arrow  is  used  since  the  end  of  the 
action  section  is  also  the  end  of  the  input  for  the  current 
table. 


Each  action  line  contains  four  entries:  an  action 
stub  of  UP  to  31  characters;  an  at  sign  to  indicate  the  end 
of  the  action  stub»  a list  of  rules  for  which  the  action  ts 
to  be  performed?  and  a semicolon  to  indicate  the  end  of  the 
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The  action  stub  is  cooiea  character  for  character 
(maximum  31)  uD  to  the  at  s i on  directly  into  the  aoDropriate 
internal  structure. 

The  format  of  the  list  of  rules  is  relatively  free- 
form in  thatf  once  again,  tabs,  spaces,  and  newlines  are 
ignored  when  aDorooriate.  The  default  entry  for  each  rule 
is  not  to  perform  the  current  action.  Thus,  to  indicate  the 
action  is  reouired  for  a list  of  rules,  that  list  of  rules, 
separated  bv  commas,  is  entered.  Mo  particular  order  of 
rule  numbers  is  reauire'i.  See  Figure  2 lines  33-37  for 
examples  of  action  lines. 

rthen  the  list  of  rules  has  been  entered,  a semicolon 
is  input  to  alert  OELTPAMS  that  the  end  of  the  current 
action  line  nas  been  ciscovered  and  that  DELTRAMS  must  per- 
form the  actions  reouired  to  determine  whether  or  not  to 
terminate  this  phase  of  operations. 

fl.  programming  techniques 

Although  any  beginning  programmer  familiar  with  C,  UNIX, 
and  decision  logic  tables  should  be  able  to  construct  a 
valid  input  oecision  loaic  table  for  DELTRAMS,  there  are 
three  specific  aspects  of  input  programming  ttiat  a more 
advanced  programmer  should  '■•now. 
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1 . Rule  Seouence 
1 

One  orocess  hy  which  a proqrammer  may  increase  the 
average  execution  speed  of  the  output  execution  module  is  by 
prooer  ordering  of  the  rules  in  the  decision  logic  table. 
After  testing  the  various  conditions  to  prepare  the  test 
mask*  that  test  mas<  is  compared  with  each  rule  in  sequence. 
Thus*  if  the  programmer  will  code  the  input  decision  logic 
table  so  that  the  rules  will  be  listed  in  decreasing  fre- 
quency of  satisfaction*  the  average  execution  time  of  the 
output  execution  module  will  be  decreased. 

3.  ELSE  / ERRuR  Action 

The  else/error  rule  and  its  associated  action  should 
be  the  subject  of  considerable  thouotit  when  programming 
decision  logic  taoles.  If  they  are  improperly  used  the  exe- 
cution speed  of  the  cuout  module  can  be  seriously  degraded. 
This  degradation  in  performance  results  from  the  output  code 
testing  the  test  masks  against  each  rule  mask  with  no  match 
until  the  final  else  is  found.  Eor  this  reason  it  is  recom- 
mended that  the  else/error  action  only  be  performed  for  very 
infrequent  t ransac t i ons  . 

In  the  event  that  a programmer  is  convinced  that  no 
else/error  action/rule  is  needed*  provisions  have  been  made 
for  a null  else/errcr  action  entry.  To  input  a null 
else/error  action*  the  first  non-blank  and  non-tab  character 
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after  the  'e'  or  'E'  in  the  option  section  should  be  the  at 
sign.  Mote  that  a ni’ i 1 action  is  not  a no-operation.  In 
particular^  do  not  use  a null  action  for  the  else/error 
option  if  a return  is  really  intendeo.  A null  action  for 
the  else/error  action  causes  the  last  input  rule  to  become 
the  default  action  in  order  to  avoid  the  last  test  of  bit 
masKS  for  the  sake  of  speed. 


TABLE  SLIMMARr  FOLLOWS 

table  Number  i. 

number  of  conoitions 
numbe  r of  rules 
number  of  actions 


CONOITIONS; 


RULES: 


r Ic  J <0 
s (cl  < 0 
t (cl  < n 


o'  y y V y n 

(f)  V y • 

(t)  V n n V - 


alt  TUNS: 

orintf("T<0:")  T)X  X 

p r i n t f ( " S < 0 : " ) nl  x X 

orintf("R<0\n"J  n^^XXXX 

rpos  ( 1 i? 

****  NULL  ELSE/ERPOR  ACTION  **** 

Taole  1 is  complete  and  non-amb i quous . 


t 5.  Examole  of  formatted  Cutout  from  DFLIRANS 
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S.  Action  Seaupnce 

When  a carticular  rule  is  satisfied^  the  actions 
designated  for  that  rule  are  oerformed  in  the  order  listed. 
If  severe  prograr^minq  difficulties  should  arise  from  this 
restriction,  the  problem  may  he  eased  by  listing  an  action 
in  more  than  one  place  in  toe  incut  decision  logic  table. 
This  will  not  affect  the  size  of  the  output  execution 
module. 


C.  OUTPUT  GENERATED 

OELTRANS  not  only  generates  a codec  execution  module  but 
also  generates  a formatted  decision  logic  table  for  program- 
mer use  in  documen t a t i on  and  debuoaing. 


Ricure  3 contains  tne  formatted  output  from  the  example 
program  in  Fipijre  2.  This  formatted  output  is  written  into 
the  standard  outnuf.  (See  section  III  for  a discussion  of 
input  and  output  files.)  In  Fiaure  3 the  table  number  is  on 
line  y.  Lines  5 throuoh  7 contain  a summary  of  the  program- 
mer input  for  number  of  rules,  actions,  and  conditions. 
Lines  9 throuch  21  display  the  four  Quadrants  of  the  deci" 
sion  lodic  table.  Line  soecifies  the  else/error  action 
and  the  last  line  contains  the  ambiguity  anc  completeness 
message.  Error  messaoes  are  also  directed  to  the  standard 
output.  See  section  Iv  tor  error  messages  and  sugaested 
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; 


correcting  actions.  Section  III  contains  oroceOures  for  tfie 
correction  of  errors. 

The  coded  execution  module  is  written  into  the  output 
file.  The  format  of  this  code,  while  difficult  to  under- 
stand at  first  alance,  can  assist  the  programmer  in  debug- 
ging syntax  errors  in  input  decision  logic  tables.  Figure  ^ 
contains  the  code  generated  by  DFLTRANS  from  the  input  pro- 
gram, in  Figure  2.  Line  20  in  Figure  2 contains  the  name  and 
parameters  for  the  subroutine  which  appear  in  Figure  y on 
line  IR.  In  Fioure  R,  line  23  contains  the  declarations  for 
the  rule  masks  f dda ) , ano  the  test  maskCddb  ang  adc ) . Lines 
2S  through  29  initialize  the  test  mask  and  rule  masks. 
Lines  30  throuah  35  provide  the  code  to  test  the  conditions 
and  set  the  test  mask.  The  remainder  of  the  code  searches 
for  a match  between  a specific  rule  mask  ana  the  test  mask, 
and  also  contains  the  actions  to  be  executed  it  a match  is 
found . 

The  'n'  or  'N'  option  placed  the  subroutine  name  in  the 
ouput.  The  'r'  ana  'c'  options  determined  the  number  of 
tests  to  be  Performed  and  the  number  of  rule  masks.  The  'a' 
option  merely  limits  the  number  of  actions  to  the  internal 
storaae  reauirements  in  DELTRArJS.  The  final  else  is  used 
for  the  final  rule.  '(ote  that  the  actions  and  conditions 
appear  in  the  output  in  the  same  order  they  have  in  the 
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1 

i nt 

r (6) 

{ 0, 

1 ,-2,-3, 

2,- 

3)  ; 

2 

i n t 

S 161 

{-a. 

R,-7,  0, 

-4,- 

1 > ; 

3 

i n t 

t [6) 

{-1  , 

5,-2,-l , 

0, 

3}  ; 

4 

5 

main 

( ) 

( 

6 

i nt 

k ; 

7 

for 

(k=0;  k<6;  k+t)  { 

8 

pr i nt  f ( " 

\n  r he  numbers 

t o 

9 

10 
1 1 
12 
13 
Id 

15 

16 

17 

18 

19 

20 
21 
22 
23 

2d 


print f("\tP  = 
pri nt  f ( "\t  T = 
1 oat  ab  ( k ) ; 


%d\n\tS  = 
•/d\n"  , t (kl 


test  are 
%d\n" , r Ik) 
) ; 


:\n"  ) ; 

f S ( k ) ) 


roos  ( ) { 


printf("R  is  ocsitive.Xn") 


} 


1 ogt  ab (c  ) 
i n t a ; 
c r a r b ; 


1 n t 


int  ddalSl  [21  »ddb»ndc, 
adb=0;  ddc=  0160000  , 


25 

dda  101  10) = 0 160000; 

Q 

a 

Q) 

o 

(11  = 

00 ; 

26 

dda  [ 1 1 (01  = 0 1 40000; 

dda  ( 1 1 

(11  = 

0 2 0.0  0 0 ; 

27 

dda  (21  (0) = 01  GOOOO; 

dda [ 2 1 

(11  = 

060000; 

26 

dda  ( 5)  (0) = 0 1 20000; 

dda  (31 

(11  = 

040000; 

29 

dda  (4)  [01  = 0600  0 0; 

dda  (41 

111  = 

0 1 60000 ; 

50 

i f ( r (c 1 < 0 ) ( 

31 

ddh  =!  0 1 00000  ; 

ddc 

= & 

077777  ; > 

52 

i f ( s ( c 1 < 0 ) { 

53 

dab  = I ■ii4  00  00  ; 

ddc 

= & 

0137777; 1 

34 

i f ( t (c)  < 0 1 { 

35 

dab  =!  020000; 

ddc 

= H. 

0157777;) 

36 

if((dda(0)  (0)8iCdb)  = 

= ddb 

(dda(01  ( 1 1 &ddc ) = = ddc  ) < 

37 

arintf("r  < 

0 : " ) 

38 

printf("S  < 

0 ; " ) 

39 

pr  i nt  f ( "R  < 

0 \n  ") 

; ) 

40 

else  i f ( ( dda  ( 1 1 

(01 Sddb) 

= = ddb 

( dda ( 1 1 

41 

orintff"S  < 

0 : ") 

4? 

p r i n t f f " R < 

0 \n  ") 

; } 

43 

else  if((dda(21 

[ 0)  (iddb  1 

= = ddb 

(dda (21 

44 

orintf("R  < 

0 \ n "1 

; } 

45 

else  i f ( ( dda  ( 51 

(01  'Iddhl 

= = ddb 

( ada  (3) 

1 1 1 Sddc ) = = ddc  ) ( 


I 1 1 Xddc ) = = ddc  ) i 


1 1 ) !4adc  ) = = ddc  ) { 


a6 

47 

48 

49 

50 


D r i n t ^ ( 
D r i n t f ( 
se  { 

r DOS ( ) 


\ n 


) ; } 


FIGURE  4,  Exa'^ple  Source  Code  trom  UtLIRAt<S 
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III.  EXECUTING  YOUR  JOB 


A.  INITIATING  CEL  TRANS 


The  comtranri  line  Tor  DELlRA^iS  has  the  form  of  "deltrans" 
followed  by  the  inout  aro  outrut  fi1enarres»  if  desired. 

If  there  are  no  files  specified/  OELTRANS  will  open  the 
Stan, 3am  input  for  input  and  create  the  file  "d.tab.c"  for 

C U f DIJ  t . 

It  there  is  only  one  file  naire  specified/  DELTRANS  will 
open  that  file  for  incut  and  create  the  file  "d.tab.c"  for 
out  put  . 


If  there  are  t..,o  fiienatres  specified/  OELTRANS  will  open 
the  first  file  for  inout  and  create  a file  for  ouout  using 
the  second  filename. 


If  there  are  more  than  two  filenames  specified  in  the 
command  line/  the  first  two  are  used  for  input  and  output/ 
and  an  error  message  is  produced  alerting  the  programmer 
that  the  system  detected  an  error  in  the  command  line. 

It  the  programmer  wishes  to  l/eeo  a record  of  the  format- 
ted table  Summaries  and  error  messaaes/  he  may  do  so  using 
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the  ">"  and  "I"  provided  by  UM x for  redirecting  the  stan- 
dard output  to  a file  or  device. 

If  the  code  in  Figure  2 >»as  in  file  "fig2"»  then  the 
command  "deltrans  fip2  fiq^  > fig3"  would  generate  the  out- 
put code  in  file  "fia^"»  and  redirect  the  table  summary  to 
file  "fig3".  Figure  ^ contains  the  code  that  would  be  gen- 
erated in  file  "fig^"  and  Figure  3 contains  the  table  sum- 
mary that  would  be  in  file  "fig5". 

Since  the  output  from  DELTRANS  is  C source  code  and  must 
be  compiled  prior  to  execution,  file  names  must  be  of  the 
form  "*.c". 

B.  ERROR  PROCEDURES 


DELTRANS 

is  designed 

to  detect 

a numbe r of 

errors  dur 

i ng 

execution. 

A list  of 

error  messages  is  in 

section  IV 

0 f 

this  manual 

along  with 

s uaae s t ed 

D roara"''T>e  r 

response 

t o 

recover  from  each  error.  The 

f 0 1 low! nq 

di scuss i on 

1 s 

directed  af  classifying  the  errors  by  type. 

Ambiguity  and  completeness  checking  results  in  warning 
messages  (program  execution  continues)  when  a redundant  or 
incomplete  decision  logic  table  is  encountered.  Incon- 
sistent taoles  and  actionless  rules  cause  error  message  gen- 
eration and  deltrans  discontinues  processing  of  the  current 
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table.  See  chapter  V of  the  parent  thesis  for  a discussion 
of  ambiguity  ana  completeness  checkina. 

File  errors  are  discovered  by  the  system  and  communi- 
cated to  OELTRANS  for  error  message  generation.  All  file 
errors  cause  immediate  termination  of  preprocessing. 

Errors  in  the  option  section  include  both  numerical 
value  and  syntax.  Value  errors  result  when  invalid  numerals 
(too  larae»  too  small,  improperly  formed)  are  encountered. 
Additionally.  missing  or  duplicate  entries  for  reauired 
options  cause  error  message  aeneration  and  termination  of 
taole  preprocessing. 


Stub  errors 

(el se/error. 

action. 

and 

c ond i t ion) 

are  nor- 

mally  caused 

b y 

exceed! nq 

the  1 

i m i t 

on 

stub 

1 ero t ^ or 

failure  to  use 

the 

del i m i t e r . 

•a' , 

i n 

the 

proper  place. 

Table  preprocessing  is  terminated  when  a stub  error  is 
detected. 

. t 

Action  and  condition  entry  errors  are  caused  bv  either 
syntax  or  invalid  rule  nvjmerals.  Both  of  these  are  fatal 
errors  in  that  pr**orocessing  of  the  current  table  is  discon- 
t i nued . 

Tally  errors  result  when  tne  actual  numbnr  of  input 
actions  or  conditions  does  not  aaree  with  the  number  speci- 
fied in  the  option  sncticn.  Because  seyeral  arrays.  inter- 
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nal  to  UELTRANS»  have  been  initialized  using  the  value  in 
the  option  section,  this  error  causes  termination  of  prepro- 
cessing for  the  current  table. 

Numerical  value  errors  can  occur  in  many  sections  of  the 
input.  They  result  from  excessively  large  numerals,  exces- 
sively small  numerals,  or  improperly  formed  numerals.  The 
numerals  are  resized  by  substituting  the  largest  permitted 
number  for  that  usage.  An  error  message  is  generated  and 
DELFRAfiS  attemots  to  continue  execution.  However,  no  output 
cooe  will  be  generateo,  onlv  error  checking  will  be  Per- 
f o rmeo  . 

Few  errors  cause  immediate  termination  of  preprocessing. 
Normally  DELTWANS  will  attempt  to  resynchronize  the  input 
stream  ang  continue  oreorocess i ng  in  an  attempt  to  generate 
a formatted  taole  for  programmer  use  in  debugging.  This 
attempt  to  generate  assistance  for  the  programmer  will 
include  not  only  the  generation  of  a formatted  table,  but 
also  will  include  the  generation  of  some  output  code  when- 
ever Possible.  However,  this  is  forced  output,  generated 
only  to  assist  in  debugging.  Seldom  will  executable  code 
result  when  an  error  has  been  detected. 
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C.  CHANGING  THE  INPUT  DATA 


Since  DELTRANS  was  constructed  to  preorocess  a file  or 
input  w i t R multiple  decision  logic  tables  imbedded  in  that 
input#  there  is  no  method  available  to  the  programmer  to 
alter  the  preprocessor  actions  other  than  alter  the  input 
data  and  preorocess  the  data  again.  For  this  reason  the 
programmer  is  strongly  encouraoed  to  oreoare  the  input  as  a 
file  rather  than  enter  it  from  the  terminal. 


D.  CO'^PILATION  AMO  EXECUTION 


The  output  file  oenerated  by  DELTRANS  contains  both  the 
C code  from  the  input  prooram  as  well  as  the  C code  gen- 
erated by  the  preprocessor . In  order  to  execute  the  program 
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IV.  ERROR  MESSAGES 


A user  may  receive  one  or  more  error  messages  at  his 
terminal  during  d r ec rocess i ng . They  may  cause  immediate 
processing  termination  or  may  only  be  a warnina  to  point  out 
possible  faulty  logic.  In  either  case/  this  section  may  be 
used  as  a guide  for  error  identification  and  correction. 


A1  1 

as  they 
t i on  and 
messages 
1^6)  and 


possible  DELTRA''iS  error  messages  are  presented  here 
will  appear  at  the  terminal/  along  with  an  explana- 
regui red  user  response.  In  the  event  any  other 
appear  at  the  terminal/  the  UNIX  Progammer's  Manual 
the  C Reference  Manga!  (231  should  be  consulted. 
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A.  EARNING  MESSAGES 


A list  of  processor  generated  warning  messages  follow. 
Those  not  considered  self-explanatory  are  given  an  error 
number  for  reference. 


aARNING  *****  duplicate  entries  for  number  of  actions. 


EARNING  *****  duplicate  entries  for  number  of  conditions. 


WARNING  *****  duplicate  entries  for  number  of  rules. 


WARMING  *****  option  value  less  than  or  equal  to  zero  in 
line  X . 


WARNING  *****  duplicate  rules  specified  for  action  Y line 

X . 


WARNING  *A0R*  rules  X and  Y in  table  Z are  redundant 


WARNING  *A03*  table  Z is  incomplete. 
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B.  AMBIGUITY  AND  COMPLETENESS  ERRORS 


ERROR  *A01* 

si  stent  . 

rules  X and  Y 

make  table 

Z incon- 

EXPLANATION: 

In  table 

number  Z , rules  X 

ana  Y can 

be  spec i - 

fieri  by 

the  same  set  of 

condi t i ons . 

However, 

they  reauire  different  actions  and  thus  make  the 
table  logic  faulty.  Further  processing  on  table 
Z was  terminated. 


RESPONSE : 

1.  Examine  carefully  rules  X and  V.  Note  that 

all  "don't  cares"  ('-')  can  be  expanded  to  both 
a "y"  ana  a "n"  entry.  Also  a is  equivalent 

to  a "n"  and  a '"6"  is  eauivalent  to  a "y". 

2.  Alter  rules  X and  Y to  remove  the  logic 
error. 


A02;  nARNING  * ^0  2 * rules  X and  Y make  table  Z redundant. 


EXPLANATION: 

In  table  number  Z,  rules  X and  Y can  be  satis- 
fied by  the  same  set  of  conditions.  Further- 
more/ they  specify  the  same  action  and  thus 
either  one  rule  can  be  removed  or  the  two  rules 
combined.  Table  processing  was  not  terminated 
due  to  this  warnino. 
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RESPONSE: 

Re'nove  the  redundancy  by  either  removing  one 
role  or  combining  the  two. 


A03;  /lARNiNG  *A03*  table  Z is  incomplete. 


EXPLANATION: 

This  warning  is  generated  to  alert  the  user  that 
the  logic  in  table  number  Z does  not  consider 
all  oossible  combinations  of  conditions.  In 
adoition»  the  else/error  action  is  a null 
action.  Table  orocessing  was  not  terminated  due 
to  this  warning. 


RESPONSE : 

1.  Ensure  all  missing  rules  would  only  be 
satisfied  by  imoossible  condition  outcomes. 

2.  If  it  can  not  be  shown  that  all  missing 
rules  are  impossible#  enter  an  appropriate  error 
action. 

3.  If  all  missina  rules  are  impossible#  ignore 
the  warning.  The  table  output  follows 
orescrioec  looic. 


AOQ:  ERROR  ♦AOa*  no  action  specified  for  rule  X. 


EXPLANATION: 

Internal  ambiguity  checks  reveal  that  rule  X has 
no  associated  actions. 


RESPONSE : 

1 . 
2. 

nu  1 


Recheck  format  and  Ionic. 

To  implement  a true  no-action  rule# 
action  and  specify  that  action  for 


i nou  t a 
rule  X . 
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C.  FILE  ERRORS 


FOl:  ERROR  *F01*  unable  to  ooen  'd.tab.c'  for  output. 


EXPLANATION: 

UNIX  coulo  not  open  the  default  output  file 
"d.tab.c"  for  output.  File  errors  cause  termi- 
nation of  preprocessing. 


RESPONSE ; 

1.  Ensure  prooer  format  of  translator  cal)  line. 

2.  If  there  are  no  other  program  errors*  contact 
a consultant. 


F02;  ERROR  *F02*  unable  to  ooen  FILE  for  input. 


Explanation: 

UNIX  coulc  not  open  the  given  file  for  input. 
File  errors  cause  termination  of  processing. 


RESPONSE: 

1.  Ensure  orooer  format  of  translator  call 
line. 


2. 

Ensure  o i 

V en 

file  exists. 

5. 

If 

there 

a re 

no  other  program  errors* 

con- 

t ac  t 

a 

consul 

t ant 

• 
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F03:  ERROR  *F05*  unable  to  open  FILE  for  output. 


EXPLANATION; 

UNIX  coulo  not  ooen  the  qtwen  file  for  output. 
File  errors  cause  termination  of  processing. 


RESPONSF : 

1.  Ensure  proper  format  of  translator  call 
line. 

If  there  are  are  no  other  proaram  errors 
contact  a consultant. 
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D.  RULE  NUMBER  IN  ACTION  DR  CONDITION  ENTRY 


LOl;  ERROR  *LOl*  Hn<?  X, 


Explanation: 

The  action  entry  on  line  X specifies  that  that 
action  is  to  be  performed  for  a rule  number  that 
is  qreater  than  the  maximum  number  of  rules 
declared  in  the  notion  section.  Processing  will 
be  terminated  for  this  table  if  the  error  count 
exceeds  the  maximum  allowable. 


RESPONSE: 

1.  Checx  the  indicated  line  to  ensure  the  for- 
mat is  correct  . 

2.  Checi<  the  largest  number  in  the  line  against 
the  number  of  rules  soecified  in  the  program 
option  section. 


L02:  ERROR  ♦LO?*  line  X, 


EXPLANATION; 

A condition  entry  specifies  a condition  is  to  be 
tested  for  an  invalid  rule  number.  Processing 
will  be  terminated  for  this  table  if  the  error 
count  exceeds  the  maximum  allowable. 


RESPONSE : 

1.  Check  that  all  rule  numbers  in  the  specified 
entry  line  are  no  larger  than  the  maximum  speci- 
fied in  the  option  section. 
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2,  Examine  line  X for  format  errors. 


L03:  ERROR  *L03*  line  X. 


explanation; 

A condition  entry  contains  an  invalid  list  of 
rule.  Processinc  will  be  terminated  for  this 
table  if  the  error  count  exceeds  the  maximum 
a 1 1 owab 1 e . 


RESPONSE ; 

1.  Check  for  prooer  format  of  line  X. 

2.  Ensure  all  rule  numbers  are  greater  than 
zero. 

3.  Ensure  all  rule  numbers  are  no  larger  than 
the  maximum  rule  number  specified  in  the  option 
section. 

A.  Ensure  the  second  number  in  a list  is 
greater  than  the  first. 


L0<4;  ERROR  *L0a*  line  x. 


ExPLAnat 10 M: 

An  action  or  condition  entry  specifies  a rule 
number  that  is  not  in  the  specified  range. 


RESPONSE: 

Check  that  all  rule  numbers  in  the  specified 
entry  line  are  no  larger  than  the  maximum  speci- 
fied by  the  program. 
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E.  OPTION  SECTION  ERRORS 


NOl:  ERROR  *M01*  initialization  error. 


EXPLANATION: 

The  number  of  ru)es»  actions#  and  conditions 
must  all  be  initialized  in  the  option  section. 
In  addition  they  must  all  be  areater  than  zero. 


RESPONSE : 

Ensure  that  all  rules,  actions.  and  conditions 
are  initialized  and  in  the  proper  format.  The 
number  must  follow  the  option  on  the  same  line 
as  the  option. 


NOl?: 


ERROR 

ERROR 

ERROR 


*N02*  missinq  subroutine  name. 

*N02*  subroutine  name  missinq  from  options. 
*N02*  subroutine  name  exceeds  8 characters 
nea  r line  X . 


explanation: 

The  option  section  for  each  decision  loqic  table 
must  contain  the  option  "n”  which  specifies  the 
name  of  the  subroutine  into  which  the  decision 
logic  table  will  be  converted.  Processino  of 
the  current  table  is  halted  when  unable  to  find 
the  subroutine  name. 


RESPONSE: 

1.  Checi<  for  proper  format  of  the  "n"  option. 


PO 
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2.  Ensure  the  n.ime  is  no  longer  than  8 
ters  anrj  is  seoarated  from  the  parameter 
a space. 

3.  Ensure  the  name  is  on  the  same  line 


c ha r ac  - 

list  hy 
as  the 


N03:  EKRUR  *N03*  unrecoan i eab 1 e option  'O'  line  X. 


EXPLANATION: 

An  unrecognizable  option  has  been  oetected  on 
line  X.  'O'  is  the  character  DELTRANS  found 
when  it  was  exoectinq  an  option  character. 


RESPONSE : 

1.  Ensure  the  orooer  format  is  used.  Notice 
that  no  punctuation,  other  than  soaces,  is 
valid  in  the  option  section. 

2.  See  also  error  NO^. 


NO'4:  ERROR  *N0^*  invalid  numeral  'O'  near  'P'  line  X. 


EXPLANATION: 

An  invalio  numeral  has  been  Oetected  on  line  X 
following  P . 


RESPONSE: 

1.  Ensure  that  the  proper  option  format  is 
used,  including  the  circumflex. 

2.  The  number  must  follow  the  option  on  the 
same  line  as  the  ootion. 

5.  iNhen  the  logic  table  translator  drops  syn- 
chronization in  the  option  section,  error  NOS 
and  NOO  are  repeated  while  resync ron i zat i on  is 
attempted.  This  is  an  indication  of  invalid 
option  letters,  format,  or  punctuation. 
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N05; 


N06: 


t 


ERROR 

* N 0 5 * 

Y. 

i nva  1 

i d 

number 

ERROR 

*N05  * 

Y. 

> 

c 

i d 

numbe  r 

ERROR 

*N05* 
to  Y . 

> 

C 

i d 

number 

of  rules  line  X set  to 
of  actions  line  X set  to 
of  conditions  line  X set 


EXPLANATION; 

The  option  section  of  the  input  proqram 
requested  that  either  the  number  of  actions# 
conditions#  or  rules  exceed  the  maximum  permit- 
ted by  the  translator. 


RESPONSE: 

1.  A series  of  small#  linked  tables  are  recom- 
mended . 

2.  Check  line  X to  ensure  the  option  size  is  as 
needed . 

3.  A consultant  can  enlarge  the  processor  for 
special  applications. 


ERROR  *N06*  ceclarations  found  prior  to  subroutine 
name . 


explanation: 

The  ODtion  section  must  contain  the  "n"  toqgle 
prior  to  the  "d"  toqqle  to  perform  proper  cod- 
inq.  No  further  processing  on  the  current  table 
is  at  temp  ted. 


RESPONSE: 

Edit  the  option  section  of  the  table  and  place 
the  "n"  toqqle  before  the  "d"  togqle. 
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N07;  ERROR  *N07*  invalid  oarameter  list 


EXPLANATION; 

The  format  of  the  parameter  list  is  in  error. 
The  translator  has  recoanized  and  accepted  the 
name  of  the  subroutine  but  is  unable  to  find  a 
valid  list  of  parameters.  Output  has  been 
forced  into  the  specified  output  file  as  a pos- 
sible a i ri  in  debuqqing. 


RESPONSE : 

Loc a t e the 
the  table 
that  a "T" 


'n*  tooale  in  the  option 
and  correct  the  format 
must  be  i nc 1 uded. 


section  of 
error.  Note 


M08;  ERROR  *N08*  else/error  syntax  line  X. 

ERROR  *N08*  missing  else/error  action  line  X, 


EXPLANATION: 

ELSE/ERROR  actions  are  reauired  for 
sion  loaic  table  to  be  processed 
If  no  action  is  desired  a "ea)"  will 
action.  Proper  format  reauires  that 
be  on  the  same  line  as  the  toggle  "e" 


every  dec i - 
by  DELTRANS. 
set  a null 
the  action 


RESPONSE  : 

Correct 


the  format  error  on  line  X. 
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F.  ACTION  AND  CONDITION  STUB  ERRORS 


SOI;  ERROR 
ERROR 
ERROR 


* S 0 1 ♦ 

* S 0 1 * 
*S0  1 * 


invalid  else/error  stub  line  X. 
invalid  action  stub  line  X. 
invalid  condition  stub  line  X. 


EXRL  ANAT ION: 

An  improperly  formed  stub  has  been  detected. 
Table  process i na  is  terminated  when  this  error 
occurs . 


RESPONSE ; 

Ensure  proper  format  of  the  stub  on  line  X»  in 
particular  that  the  "il"  is  in  position  and  that 
the  stub  contains  no  more  than  31  characters. 


SO^:  ERROR  *30^*  invalid  condition  stub  line  X. 


EXPLANATION: 

Fmotv  conaition  stubs  are  invalid.  The  output 
code  will  fail  to  compile  since  a test  of  a null 
condition  would  be  reouired. 


RESPONSE : 

Check  the  format  on 


line  X . 
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G.  ACUOrj  A^JD/OR  CUNDITIOM  TALLY  ERRORS 


TOl:  ERROR  * T 0 1 * number  of  actions  not  as  specified  in 

option  section. 


EXPLANAriON; 

Internal  checks  indicate  the  actual  number  of 
actions  input  does  not  eoual  the  number  of 
actions  specified  in  the  option  section.  Table 
orocessinq  has  been  terminated  after  forcing 
table  summary  output. 


RESPONSE  : 

Check  the  numoer  of  actions  and  the  format  of 
the  option  statement.  The  output  table  will  aid 
in  locating  the  error. 


T02:  ERROR  *T02*  number  of  conditions  not  as  specified 

in  notion  section. 


EXPLANATION: 

Internal  checks  indicate  the  actual  number  of 
conditions  input  does  not  equal  the  number  of 
conditions  specified  in  the  option  section. 
Fable  processing  has  been  terminated. 


RESPONSE : 

Ensure  that  the  ootion  number  and  the  format  are 
correct.  See  the  cutout  table  for  summary 
debuqqino  assistance. 
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h.  numerical  value  errors 


VOl;  ERROR  *V01*  excessive  value  line  X set  to  MAX. 


E XPLANAT  IU!vi: 

An  inteaer  larqer  than  any  valid  value  in  the 
translator  has  been  detecteo.  Further  process- 
ina  will  be  atter^Dted. 


RESPONSE  : 

1.  Check  integer  size  on  line  X. 

2.  Ensure  orooer  for'T'at  ud  to  ana  including 
line  X . 

3.  See  error  NOS. 


V02:  ERROR  *V02*  invaliH  numeral  'O'  line  X. 


EXPLANATION: 

An  improperly  formed  string  of  numerals  has  been 
enc  oun  t e r ed . 


RESPONSE : 

Ensure  that  all  strings  of  numerals  are  in 
proper  format  and  that  no  characters  other  than 
integers  appear  in  the  string. 


1 OS 
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V03:  ERROR  *V03*  line  X. 


EXPLANATION; 

A non-existent  rule  number  apoears  in  the  action 
entry  on  line  X. 


RESPONSE  : 

Check  all  rule  nuirbers  in  action  entries  to 
ensure  that  they  are  qreater  than  zero  and  are 
of  the  proner  fortrat. 


voa : ERROR  * voa » line. 


EXPLANATION : 

A non-existent  rule  number  appears  in  the  condi- 
tion entry  on  line  X, 


RESPONSE : 

Ensure  all  entries  refer 
rules.  Check  the  format 


t o 
o f 


positive  non-zero 
the  condition  entry. 


1 06 


I . 


XO  1 


X02 


X03; 
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SYNTAX  ERRORS 


ERROR  *X01*  stateirent  syntax  line  X. 


EXPLANATION; 

A syntax  error  was  discovered  by  DELTRANS  in 
line  X . 


RESPONSE  : 

Review  the  format  uo  to  and  includina  the  line 
indicated. 


ERROR  *X02*  statement  syntax  line  X. 


Explanation: 

A syntax  error  was  discovered  by  GELTRAfJS  in 
line  X.  At  the  time  of  the  errors  OELTRANS  was 
attemotinc  to  decode  a condition  entry  list. 


RESPONSE : 

Review  the  format  up  to  and  including  the  line 
indicated. 


ERROR  *X03*  statement  syntax  line  x.  I 

i 

I 

I 

EXPLANATION:  | 

A syntax  error  was  discovered  by  DELTRANS  in  ! 

line  X.  At  the  time  the  error  was  detected 
DELTRANS  was  attempting  to  decode  an  action 
entry  list. 
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RESPONSE: 

Review  the  action  list  forinat  up  to  and  includ- 
ing the  line  indicated. 
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V.  GLOSSARY  OF  TERMS 


Action: 

Something  to 

be 

oone  predicated 

on  the 

responses 

t o 

t he  condi t i ons 

in  the 

table.  May 

be 

computations,  goto 

state- 

ment » assiqnmentf  etc. 


Action  Entry;  The  lower  riqht  Quadrant  of  the  table. 


The 

only  en  t 

r V 

oe  r m i 1 1 ed  in 

this  sect i 

on 

for 

tables  i 

n 

limited 

entry 

format  is 

an 

••  X " . 

V\hen 

an 

"X"  is 

placed 

oppos i t e 

an 

action,  that  action  is  to  be  taken. 

Action  Line:  One  action  froTi  the  action  stub  and  its 

associated  list  of  rules  frofti  the  action 
entry. 

Action  S t a t enen t ( s ) : The  contents  of  the  action  stub. 

Action  Stub:  The  lower  left  quadrant  of  the  body  of 

the  table.  Listed  here  are  the  actions 
to  be  taken,  which  deoena  on  the  condi- 
tions in  the  condition  stub  above. 
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Complex  Rule:  A oecision  table  rule  which  contains  at 

least  one  "don’t  care"  entry. 

Condition;  A test  or  a decision  to  be  made  as  part 

ot  the  loaic  or  processinq  of  a problem. 
It  should  be  stated  in  a form  that  may 
be  answered  "yes"  or  "no". 

Condition  Entry;  The  upper  riqht  quadrant  of  the  body  of 

the  decision  table.  This  section  con- 
tains responses  to  questions  asked  in 
the  condition  stub. 

Condition  Line:  One  condition  from  the  condition  stub 

and  its  associated  list  of  truth  values 
for  rules  from  the  condition  entry. 

Condition  St  at ement ( s ) ; Contents  of  the  condition  stub. 

Condition  Stub:  The  upper  left  quadrant  of  the  body  of 

the  decision  table.  All  the  conditions 

or  tests  to  be  maoe  will  appear  in  this 

/ 

section. 

Contradiction:  A decision  lodic  error  in  which  two  or 

more  rules  have  the  same  combination  of 

1 1 0 
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ELSE  / ERROR  Rule: 


E X t endea  Ent  ry  : 


GOTO: 


Imposs idle  Rule: 


I neons i s t enc  v : 


L i m i t ea  entry; 


Condi t i ons 
specified. 


Out  nith  different  actions 
A synonym  for  inconsistent. 


f h e 

rule  that  acts  as 

a catch-a  1 1 

for 

al  1 

rules 

not 

spec  i 

f i cal  1 y covered 

i n 

the 

table. 

Its 

presence  completes 

the 

table. 

— 

A tyoe  of 
condition 
condi t i on 


decision  table  in  which  actual 
values  are  specified  in  the 
entry  part  of  the  table. 


Used  for 
statement 
t ao 1 e . 


inkinq  tables#  it  is 
which  references 


an  ac  t i on 
anot  her 


A rule  that  due  to  dependency  of  condi- 
tions is  physically  impossible*  e.q.  c < 
10  and  c > ^0. 


See  contradiction. 

A tyoe  of  decision  table  in  which  all 
conditions  are  stated  as  questions  which 


have  a 


ves 


or  no  answer 
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Mixed  Entry: 


Recurs i on : 


Redundancy : 


Rule: 


Rule  Mask: 


3 i mp 1 e Rule: 


A type  of  decision  table  in  which  both 
limited  entries  and  extended  entries 
appear. 

A synonym  for  looping.  A conditional 
branch  is  made»  depending  on  a condition 
value. 


A decision 

logic 

error  in 

which  two 

OP 

more  rules 

have 

the  same 

comb i nat ion 

o f 

conditions  with  the  same  actions  speci- 
fied. 

A sinole  column  of  the  decision  table 
that  shows  the  combination  of  responses 
to  the  conditions  and  the  resulting  or 
appropriate  actions. 

A method  of  orogram  coding  using  deci- 
sion tablesf  where  a table  matrix  is 
held  in  storaqe  and  data  matched  against 
i t . 

A rule  which  contains  no  "don't  care" 
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Table  Li nk aqe : 


A conversion  bv  which  two  or  more  tables 
are  related  by  means  of  action  transfers 
(such  as  GOTO)  from  one  to  another. 


1 1 ! 
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Xtoken  CONO  ACT  TLIST  ALIST  DIGIT  NIJV 

Xi 

u 


«def 

1 ne 

ACTLEN 

32 

// 

max 

chars  in  act 

stub 

«de  f 

i ne 

BIGINT 

6a 

// 

max 

integer  in  processor 

Ade  f 

i ne 

PLANK 

• t 

»de  f 

i ne 

CDNLEN 

52 

// 

max 

chars  in  can 

stub 

*»de  f 

i ne 

CRLF 

' \n 

1 

#def 

1 ne 

DELIM 

*o)' 

<(de  f 

1 ne 

EOF 

-1 

// 

end 

of  file  f r om 

getc  ( ) 

»de  f 

1 ne 

ERRLEN 

32 

// 

max 

chars  in  else/error  action 

«de  f 

1 ne 

GNC 

get  c ( i no ) 

//  used  for  program  clarity 

s<de  f 

1 ne 

AX  RULE 

6a 

// 

maximum  number  of 

rules 

#de  f 

1 ne 

'^AXCDN 

1 6 

// 

maximum  number  of 

conditions 

«de  f 

i ne 

MAXACT 

32 

// 

maximum  number  of 

actions 

#de  f 

i ne 

MAXERR 

S 

// 

maximum  number  of 

non-fat  a 1 errors 

*»de  f 

i ne 

NULL 

' \0 

1 

#de  f 

1 ne 

TAB 

• \t 

t 

tide  f 

i ne 

TOKN 

• *■ ' 

#de  f 

i ne 

TRUE 

1 

»de  f 

i ne 

FALSE 

0 

i n t 

enurr 

0; 

// 

number  of  errors 

int  inconsis  FALSE;  //  table  inconsistency  flag 

int  line  1»  //  line  number 

int  nexta  0;  //  index  into  action  structure 

int  nextc  0;  //  index  into  condition  structure 

int  nodec  TRUE;  //  neaative  declaration  flag 

int  noelse  TRUE;  //  no  error/else  rule  flag 

int  noname  TRUE;  //  no  subroutine  name  found 

int  numact  0;  //  number  of  actions 

int  numcdn  0;  //  number  of  conditions 

int  numrule  0;  //  number  of  rules 

int  parsact  CONO  ; //  parse  action  flag 

int  pbak  -2;  //  aux  next  character  buffer 

int  peek  -2;  //  next  character  buffer 

int  Sumact  0;  //  check  sum  on  number  of  actions 

int  sumcdn  0;  //  check  sum  on  number  of  conditions 

int  tabno  0;  //  current  table  number 


1 1 » 


deltrans  source  code 


int  ru 1 e IM A XRULE ) ; 

int  mas*  [''’‘AXRULEl  121  » 
char  »»f»act  (ERRLEM  ! 


//  Dointers  to  requireo  actions 
//  for  each  ru 1 e 

//  rule  mask  matrix 

//  error/else  action 


struct  { //  condition  stubs  and  condition 

char  cItrtCONLEM;  //  entries 

char  cent r y IMAXRULE 1 ; 

Icstufc  l''^AxCOMJ  » »cctr; 


struct  ( //  action  stubs  and  action  entries 

char  altrlACTLEM; 

Char  aen t r y A X PULE  1 ; 

lastubl^'AXACn.  *aotr; 


struct  < //  rule  action  lists 

int  ac  tot  r ; 

int  ac  t 1 t r s ; 

> f ree [BIGINT] , *fotr; 


s t rue  t i obu  f r { 
int  i Ob  t d ; 
int  i o 1 e f t ; 

Char  *ionxtn  ; 
char  i obuf  f (5121 
1 i nbuf  r outbut » 


//  both  the  incut  and  output 
//  butters 


* i no  f *ou  t r ; 


zx 

detab  ; 

conhalt  acthalt  } 

conhal t : 
coniine  I 
conna It  coniine  ; 

coniine  : 

conpart  cdnlist  ! 

conpart  : 

COiSiO  = (oetcdn();l; 


edn 1 i s t 
c I 1 s t 


1 15 


(edntest ( ) ; 1 ; 


DELTRANS  SOURCE  CODE 


1 ead  : 

1 oq  1 t r 


( ' 


cd  i q ; 

lead  DIGIT  = { fill (12);  = $2;  ) 

coma  DIGIT  = < fill (IP);  3$  = 52;  I 


cdash  ; 

coiq  DIGIT  = { f i 1 1 up ( $ 1 , $ 3 ) ; 


coma  : 
cdi  q ' 
COash 


c 1 i St 


c 1 i St  cdi q ' ) ' 
c 1 i St  cdash  ' ) 


1 oq  1 t r 

’ V ’ 

= < pee<  = 

♦ V * 

1 Y • 

= { oeei<  = 

» y * 

* n ' 

= { peek  = 

’ n • 

• N • 

= { peek  = 

* n * 

• * • 

= i peek  = 

• * • 

• - ' 

= I peek  = 

* - • 

' 5 ' 

= { peek  = 

ac  t h a 1 f 1 
a c t 1 i n e ! 
acthalf  actline 

1 : 
> ; 
> ! 
1 ! 
> ! 
> ! 
1 ; 


ac  1 1 i ne  : 

ac  t oa  rt  ac  t I i st  » 


actoapt  ; 

ACT  s (qetacti)?}; 


ac  1 1 i St  : 

nlist  = { actesti);  } 


n 1 i St  : 

nuM  = { add  rij  1 e ( S 1 » >ias  t uO  ( ne  * t a- 1 1 ) * 
parsac  t =AL  I ST  ; } ! 

pal  NUM  = { addru I e ( S2 » &as t uh  ( ne X t a- 1 ] ) ; 
oarsact  = A LIST  ; > ; 


pa  1 


nlist 


ZZ 


1 1 h 
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actest()  < /*  called  at  the  end  of  each  action 

entry  list  to  determine  what  steo 
the  preorocessor  should  take  next 
if  ( (peek  =ea  t a 1 1 ( ) ) 1=  TOKN  &8.  sumact  < numact) 

parsact  = ACT; 

else  if  ( Peek  = = T OK  IM  8.R  sumac  t = = numac  t ) 
parsact  = NULL; 

else 

sumerr("*T01*"» "actions"); 


addrule  (x,v)  int  x,  y;  ( /*  maintans  rule  pointer 

list  ("rule")»  rule  action 
list  ("free")»  and  action 
entries  in  astub  */ 

int  p t r ; 
char  *c  ; 

if  (x  > pumrule)  bad  1 oq i c ( "LO  1 " ) ; 
else  if  fx  <=  0)  badloqic("V03"); 
else  if  (*(c=  & an t r->aen t r y ( x - 1 ] ) 1 = ' x ' ) ( 

* c = ' X ’ ; 

fptr  ->  actltrs  = y) 
if  ( r u 1 e I X ] ) ( 

Dtr=fptr; 

fptr  = rule(x)  ; 

while  (fptr  ->  actptr) 

fptr=fptr  ->  actptr; 
fotr  ->  actptr  = otr; 
f Pt  r = ot  r ; 

> 

else 

rule  (xl =fptr; 

+ ♦ f Pt  r ; 

} 

else  < 

pr  i nt  f ( "t.  ARNI  NO  *****  Ouplicate  rules  "); 
printf(" specified  for  action  "); 
printf("~d  line  %d.\n"fX,line); 

> ) 


OELTRMmS  source  code 


ambiack()  { /*  ariver  ^or  ambiguity 

and  comoleteness  testing  */ 

i n t noamb i a » c » k » 
noambig  = TRUE; 

for  (c=0;  c < Cnumrule  -1);  C++)  < 

i f ( good ru 1 e ( c ) ) 

for  ( W = c+l;  k < numruteJ  k++)  { 

if  (samerole(c»k))  { 
amb i gt  vD ( c » k ) ; 
noambio  = FALSE; 

) 

} 

else 

noambig  = FALSE* 

> 

if  (qoodrule(c)  noamoig) 
c omp 1 e t e ( ) ; 
return ( i nconsi  s) } 

> 


amb i at yp ( C / k ) int  c*  k;  ( //  determines  type  of 

int  n;  //  ambiguity  that  exists 

for  (n=0;  n < numact  * n++) 

if  ( as t ub  (n 1 . aen t r y Ic 1 1=  as t ub  In)  . aen t r y ( k ] ) { 

printf("  ERROR  *A01*  Rules  X6  ",++c); 
printf("ana  %d  make  table  %d  "*++k,tabno); 
orintf(" inconsistent. \n"); 
i neons i s = TRUE  ; 
r e t 'J  r n ; 

) 

} 

printf("r(ARf>iINiG  *AOP*  Rules  Xd  and  %d  "*+  + c*+  + k); 
printf("in  table  %ci  are  redunaant.\n"*tabno); 


> 


badloqic(c)  char  *c!  i logic  error  routine 

printf("  ERROR  * Zs*  line  )!;d.\n"fC*line); 
if  ( + +enum  > i^AXERW)  bomb(); 

> 


bomb  ()  ( //  excessive  error  exit 

o r i n t f ( " P roc es s i ng  of  table  %d  halted  "*tabno); 
printf("due  to  error  count. \n")* 
k i 1 1 e X ( ) ; 


DFLTRAK'S  SOURCE  CODE 


contest  {)  { //  called  at  the  end  of  each 

//  condition  entry  list  to 
//  determine  what  step  the 
//  preprocessor  should  take 

if  ( (peek=eat a 1 1 ())!  = ' T ' sumcdn  < numcdn) 

parsact  = COND; 

else  if  (oeek=='t*  R&  sumcdn==numcdn ) { 

parsact  = ACT; 
peek  = eat  a 11  ( ) ; 

} 

else 

SumerrC"*TO^*"» "condi t ions")  ; 


completef)  { //  called  to  Determine  if  an 

//  unambiguous  table  is  complete.  Completeness 
//  testing  of  an  ambiguous  table  is  ........ 

int  c»  k;  //  ambiguous 

k = 0 ; 

for  (c=0;  c < numrule;  C++) 
k =+  totrule(c); 
if  (k  ==  (I  <<  numcdn))  { 

p r i n t f ( " T ab 1 e %d  is  complete  and  "»tahno); 
print  f("non-ambiauous.\n")  ; 
if  ( eeac t ( 0)  1 =KULL  ) { 

printf("The  else/error  rule  for  this  table  ") 
orintfC'is  superfluous. \n"); 

} 

> 

else  if  (eeactlOMrUULL)  { 

printff" FARMING  +A0^*  table  Xd  is  "^tabno); 
printf{"incomp)ete.\n"); 

> ) 

« 
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c ooy c ode ( 1 t r ) char  Itr  ; ( //  copy  code  to  output  file 

int  W,  z;  //  up  to  but  excluding  Itr 

*»hile((k=GNC)  > EOF)  < 
if  ( k ==  Itr) 

ret  urn  ( TRUE  ) ; normal  exit 

switch  ( k ) { 

case  : case  : //  direct  copy  of  quotes 

Dutc (k,outp) ; 

whi Ie((z=GNC)  > EOF  Hi  ^ i=  k)  < 
if(z==CRLF)  line+t; 
outc(z»outo); 

) 

if(z  ==  EOF)  thatsit(); 

Putc(?*outp) » 
break } 

case  : //  comments  are  removed 

k=Gf'JC; 

switch  ( k ) < 

case  EOF  ; //  EOF 

t h a t s i t ( ) ; 

case  : //  strip  rest 

tossline(k)?  //  of  line 
putc(CRLF^outp) ; 
break; 

case'*':  //striptoend 

CUtCOmf);  //  of  comment 

break ; 
case  CRLF  : 

1 i ne  * + / 

default  : //  normal  case 

putc('/'/Outp); 
outc(k»outp) ; 

) 

b reak ; 

case  CRLF  ; //  count  lines 

1 i ne  * ♦ ; 

default  : //  normal  case 

putc(k,outp); 

> } 

return(F  ALSE ) i 

//  abnormal  exit  ( fail  on  EOF  ) 

) 
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cutcom 
i n t 
wh  i i 


} 


( ) { 
c ; 

e ((c=GNC)  > EOF)  { 
if  (c==C«LF)  line++; 
else  while  (c=='*')  i 
if  ( (c  = GNC)=  = CRLn 
else  { 

if  (c=='/')  return? 
if  (c==  EOF)  thatsitC); 

) } 


//  strio  off  comments  up  to  '*/' 


// 

// 

1 i ne  + + ? 


count  lines 
end  of  comment 


thatsitC); 


} 


//  EOF 


decoclacr(p»nax»count)  //  action,  condition, 

char  *p?  //  and  rule  ootion 

int  max,  *count?  i //  number  decoder 

i nt  num  ? 

if  ( * count  1=0)  { 

pr  i nt  f ( "/jARnI  NG  *****  duplicate  entries  ")? 
printf("for  number  of  ?is.\n’*,o); 

} 

num  = gobbleC);  //  number  follows  option 

ifCnum  < 'O'  !|  num  > '9')  { / / if  not  error 

printfC"  ERROR  *N04*  invalid  ")? 
p r i n t f ( "numera 1 ' %c ' near  %c  ",num,*p); 

printfC "line  %C.\n",1ine)? 
if(++-enum  > ^^AXERR)  bombC)? 
peek  = num? 
return? 

> 

♦count  = qetvalCoum); 
i f ( ♦count  > max ) i 

printfC"  ERROR  *N05* 
printfC "line  %c  set  to 
♦ count  = max  ? 

ifC+tenum  > WAXERR)  bombC)? 


i n V a 1 i o numbe  r of 
?ld.\n",  line, max); 


% s " , p ) ? 


} 

i f 


( ‘count  <=  0 ) 
printfC  "k.'AHblUG 
printfC"or  eaua 1 


{ 


> > 


eatall  C)  < 
int  c ? 

while  C C c =oobp 1 e C ) ) ==  CRLF  ) 


* * ***  option  value  less  tnan  ")? 
to  ^ero  in  line  %d.\n",line)? 

//  eat  up  blanks,  tabs,  and  newlines 


returnCc  ) ? 


//  return  tne  first  character 


DELTRAf>iS  SOURCE  CODE 


eatc()  < //  buffereil  eatall 

int  c ; //  used  in  yyle*() 

if(pbak<0  !!  Dbak==CRLF  !!  Dbak==TAB  |!  Dbak==BLANK) 
c =ea  t a i 1 ( ) t 

e 1 se 

C =pba k ; 

pbak  = -2; 
re t urn (c  ) / 


elserrorC)  { //  decode  else/error  action 

//  and  place  in  eeactl] 
i f ( ( eeac  t [ 0 ] ='3obb  1 e ( ) ) ==  DELIM) 
eeac  t [ 0 ] = NULL ; 

else  if  feeactrO]  ==  CRLF)  { 

printf("  ERROR  *N08*  else/error  syntax  "); 
printf("line  Xn.\n"»line)» 
if  (++enun  > MAXERR)  bonnb(); 
return; 

} 

else 

strcopy(ERRLEN  -l»iieeact  111  »"else/error"); 
noe 1 se  = FALSE  » 


f a t e r r ( h » p t r ) int  h;  char  *ptr;  { //  fatal  error  routine 

switch  (h)  { 

case  1 : 

printfC"  ERROR  *F01*  unable  to  open  "); 
printfC’d.tab.c'  for  cutout. \n"); 
break; 
case  2 : 

printfC"  ERROR  *F02*  unable  to  ooen 
printf("'%s'  for  i npu t . \n " » p t r ) ; 
break; 
case  3 : 

printfC"  ERROR  *F03*  unable  to  ooen  "); 
printf("'Xs'  for  ou t pu t . \n " , p t r ) ; 

} 

printf("Execution  terminated  due  to  file  error, \n"); 
ex  i t n ; 


DELTRANS  SOURCE  COOE 


fcheck ( ) { 

char 

if  (mjfnru]e  = = 0 !!  numcdn  = = 0 I! 
u = &("\tThe  nuT-ber  of  ")/ 
printf("  ERROR  *N01* 
printf("%sru1es  is 
printf("%sconr.litions  is 
printf("5^sactions  is 
enufT>  = MAxERR  +l» 


//  check  for  proper  options 
I!  nijfTiact  = = 0)  { 


initialization  error. \n"); 
*4d.\n"»Ufnumrule); 
%d.\n",u»numcdn)  ; 
%d.\n",u»nijmact); 


i f 


> 

i f 


(nonarre)  { 
printfC  ERROR 
printf("\n"); 
enuiT>  = MAXERR  +1 


*N02*  tnissinq  subroutine  narne.")» 


C noe 1 se ) < 

printfC  ERROR  *N08* 
printf(" action  line  %d 
if  (++enum  > MAXERR)  bonb()» 

) 

if  (enun  > MAXERR)  bomb ( ) » 
peek  = ea  t a 1 1 ( ) ; 


missinq  else/error  "); 
\ n " , 1 i n e ) ; 


fill  (c)  int  c ; { //  insert  loaic  letter  into 

if  (c  > numrule)  bad  1 oq i c ( "L 02 ” ) ; //  centry 

else  if  (c  <=  0)  bad  1 oq i c ( " V 0 y " ) ; 
else  CDtr  ->  centrylc  *"  11  = peek; 

) 


fillup  (a»b)  int  a/b  ; { 

//  insert  loqic  letter  into  centry  list 
int  i ; 

if  ( a > 0 8.ii  a <=  b &>4  b <-  numrule)  < 
for(i  = a;  i <=  b)  i++) 

cotr  ->  centryli  - 11  = peek; 

> 

else  i 

printfC "Invalid  condition  entry;  '%d“Zd'\n",  at  b); 
badl oqi c f "L03" ) ; 

> ) 
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findacr()  { driver  for  option  decoding 

i nt  c ; 

while  ((c=qobc())  > EOF)  i 
switch  ( c ) { 

case  CRLF  ; //  end  of  line 

break; 

case  : //  rest  of  line  is 

tossline(c);  a comment 

break; 

case  'n'  ; case  'M*  ://  subroutine  name  follows 

namsub ( ) ; 
break; 

case  'd'  : case  '0*  ://  only  declarations  remain 

i f ( noname  ) i 

nrintfC"  ERROR  *Ni06*  declarations  "); 
D r i n t f ( " f ound  prior  to  subroutine  na"); 
nrintfC " me. \npxecut ion  terminated. \n”); 

<1  1 I e X ( ) ; 

} 

oeek  = ' T ' ; 

if  ( c OP VC  ode (oee k ) ) { 

nodec  = FALSE; 
break ; 

} 

thatsitC);  //  EOF  encountered 

case  'r'  : case  'R'  : //  options 

decodacr ( "rul es" »MAXRULE»  &numru1  e) ; 
break; 

case  'c'  ; case  'C'  : 

decodacr("condi  t ions''/MAXCDA/*Snumcon)  ; 
break ; 

case  ' a ' : case  ' A ' : 

decooacr("act  ions"»*^AXACT  »&numact ) ; 
break; 

case  'T’  : //  end  of  section 

fcheckC);  //  check  options  all  defined 

return; 

case  'e'  : case  'F'  ; //  else/error  action 

e 1 se r ro r ( ) ; 
break; 
default  : 

printff"  ERROR  *003*  unrecoqn t zab 1 e "); 
printf("oPfion  ' Xc ' line  ^d.Xn",c»line); 
if(+  + enum  > f^AxFRR)  bombC); 

) } 

thatsitC);  //  unexpected  end  of  file 

) 


l^u 
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//  error  in  subroutine  name 


f suber  r ( k ) i nt  k ! ( 

orintfC  ERROR  *N02* 
switch  (k1  { 

case  1 : 

orintfC^Subroutine  name  missinq  from  options"); 
printf(".\n\nExecut ion  terminated.Nn"); 
k i 1 1 e X ( ) ; 
case  2 : 

p r i nt f (" sub  rout i ne  name  exceeds  0 characters  ")» 
printf("near  line  ")» 
printf("Xd.\n"» 1 ine); 
if(++enum  > VAXERR)  bomb(); 

> ) 


qencode ( ) { 

qenmasks ( ) ! 
gen i n i t ( ) } 

qsetmask  ( ) ; 


> 


genst  at  s ( ) ; 
aeneo  t ( ) ; 


//  driver  for  table  output 
//  code  for  declarations 
//  code  to  initialize  masks 
//  code  to  test  conditions 
//  and  set  mask 
//  output  if-else  statments 
//  cutout  eno  of  table 


qendub ( ) < 

putc(CRLF»outp) ; 
put c ( T A8 , ou tp ) ; 
PU t C ( T A8  r OU t o ) ; 

) 


//  output  CRLE  tab  tab 


gene  1 se ( ) f 
qens i g ( ) ) 

outcode ("else  ( " ) ; 
i f (eeact  (01 ) < 

gendub ( ) ; 

outcode(iieeact  (0)  ); 
putc ( ' ; ' »outp) ; 

} 

else  ( 

fptr  = ru 1 e (numru 1 el  ; 
while  (fptr)  { 

qendub ( ) J 

outcode(fptr->act I trs) ; 

outc(’;'»outD); 

fotr  = fot r->ac tot r ; 

> > 

putc ( ' > ' »outp) ; 

) 


//  output  else  action 


12S 
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qeneotC)  < //  generate  final  " { ” for 

putc (CRLF f outp) ; //  output  subroutine 

Put c ( * ) ' * out  p ) ; 
putc(CRLF»outp); 


geninitC)  { //  output  code  to  initialize  masks 

i nt  c ; 
gens i g ( ) J 

outcode("ddb=0;"l; 

PutcnAd»outr); 
out  code ( "ddc = "); 

Ou t oc t ( 0 1 77 7 7 7 <<  (16  - numcdn)); 

outcodef" 

for  (c=0;  c < numrule;  C++)  ( 
gens i a ( ) ; 
outcode ( "dda  ["  ) ; 
out  dec  ( c ) ; 
outcode ( " ] [ 0 1 = " ) ; 
outoctCrmaskCcJ  (0)  ); 
pu  t c ( ' ; ' / ou  t o ) ; 

Outc(TAB»outp)? 
out  code ( " dda  ( " ) ; 
outdec  (c  ) ; 
outcodeC’l  (11  = ")  ; 
outoctCrmaskCc)  (11); 
cutc(';'»outp); 

> ) 

genmasks()  ( //  output  mask  declarations 

gens i g ( ) ; 

outcode("int  ddaC); 
outdec ( numru 1 e ) ! 
outcode("l  131 »ddb»odc;"); 


gensiq()  ( //  output  CKLF  TAB 

putc (CRLF  »outp) ? 
pu t c ( T AB » ou t p ) ; 
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genstats()  i //  output  if-else  statments 

i n t k / nr  ; 
i f (eeac  t lOJ  ) 

nr  = num  r u 1 e 7 

e 1 se 

nr  = num r u 1 e - 1 > 
gens i q ( ) ; 

ou  t c ode  ( " i ^ ( ( cida  [ 0 1 1 0 ] &dqb  ) = = ddb  && 
outcode(”(dda[0]  (lJ(iddc)  ==ddc){'')» 
fptr=rule(lJ  » 
while  (fptr)  { 
qendub ( ) ; 

outcode ( fpt  r->act 1 t rs)  ; 

fptr=fptr->3ctptr; 

putc(';'»outp); 

> 

putc ( ' } • »outp) ; 
for  (k=l;  k < nr  ; k++)  { 

fptr  = rule[k  + n » 
gens i g t ) ; 

out  code ( "e  1 se  ifCCddal"); 
out  dec  ( k ) ; 

outcode(")  [ 01  Sanb  ) = = ddb  "); 
out  code ( " ( dda [ " ) ; 
out  dec ( k ) ; 

outcodef"!  1 1 1 ?iGdc  ) = = ddc  ) ( " ) ; 
while  (fptr)  < 

genduD ( ) ; 

outcodef  fptr->act 1 trs)» 

outc(';'»outp)» 

fpt  r=fpt  r->actPt  r ; 

1 

pu t C ( ' 1 ' » OU  t O ) ; 

} 

gene  1 se ( ) J 


1^7 
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qetact  ()  { //  fetch  anrj  store  the  next  action 

i nt  j » 
cr»ar  *p: 

p = &astub  [next al  . a 1 t r [01  ; 
aotr  = J4a  s t ub  [ne  X t a + t J ; 

*D  = peek  ; 
peek  = -3: 
if  (*p++  !=  DELiM) 

strcopyCACTLEN  -1 ,p/ "act  ion”); 

else 

= imull; 

Surractti; 

narsac  t = AL I ST  J 

for  (j=0;  j < numri.jle;  j+  + ) 

aptr->aentry[jl  = BLAfJK  ; 


qetcdn  ()  [ //  fetch  and  store  next  conaition 

i nt  j ; 

Char  *p ; 

p = Jic  s t ub  [ne  X t C 1 . C 1 t r [ 0 1 ; 

CPtr  = &c s t ub  [ne X t c ♦ ♦ 1 ; 

*p  = peek; 
oeek  = -2; 

if  ( *p  ==  OELIM)  { 

printf("  ERROR  *S02*  "); 

or i nt f ( " Inva H 0 condition  stub  line  . \ n " ^ 1 i ne  ) ; 

k i 1 1 e X ( ) ; 

> 

St  rcoov(CDNLEn  -1 , ++D»"condi t ion")  ; 

sumcdn++ ; 

par  sac  t = Ti.  I ST  ; 

for  (j=0;  j < numrule;  j*'*') 

CPt r->cent ry  [ j 1 = 


12B 


DELTPAMS  SOURCE  CODE 


getval  (c)  int  c ; < //  decipher  a string  of  numeraJs 

i n t num  ! 
num  = c ” ' 0 ' ; 

while  ((c=GNC)  >=  'O'  c <=  'P')  { 

num  = num  *10tC“'0'  ; 

i f ( num  > blGINf)  ( 

printff"  ERROR  *V01*  excessive  value  " ) ; 
orintf("line  %d  set  to  Xd.\n"»line»  BIGINT); 
if  (ttenum  > MAXERR)  bomb ( ) » 
whi  1 e(  (c=GNC  ) 1=BLANK  Rit  cl  = TAB  RS  cl=CRLF) 
i f ( c ==  EOF  ) thatsit(); 

//  find  end  of  number 
i f (c=  = CRLF ) 1 i nett ; 

return(HIGIUT ) ; 

} } 

i f ( c ==  EOF  ) thatsit();  //  End-of“file 

if  (c  = = fiLANK  II  c = = TAI3)  return(num); 
if  (c==CHLF)  ( 

1 i ne  1 1 ; 
ret  urn ( num)  ; 

> 

printff”  ERROR  *V02*  inva");  //  error  exit 

printf("1ia  numeral  : 'Xd*'!;c'  line  %d.\n"fnum»c»line); 

if  (ttenum  > MAXERR)  bomb()» 
peeR  = c! 
return(num) ; 


gobble  ()  < //  find  first  character  other  than 

int  c ! //  a blanic  or  tab 

while  ( (c=Gr'lC)=  = BLAUK  i:  c = = TAB) 

f 

if  (c==CRLF)  linett; 

« 1 se 

if  (c  ==  EOF)  thatsitf); 
return (c)  ! 


qobc ( ) < //  buffered  gobble 

int  C!  //  used  in  findacrf) 

if  (peek  < 0 !I  oeek  = =rAB  ||  peek  = = 8LAlMK ) 
c = gobb 1 e ( ) ; 
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qoodrule(c)  int  c » ( //  each  rule  must  have  at  least 

int  k J //  one  action 

for  (ksO;  k < numact;  k+t)  ( 

if  ( as t ub  I k 1 . aen t r V (c 1 = = ' X ' ) 
ret  u r n ( I RUE  ) ! 

} 

i nc ons i s = TRUE  » 

printf("  ERROR  ♦A0^4*  no  actions  specified 
printf("for  rule  %c.\n 
return(FALSE) ! 


qsetmask()  { //  output  code  to  test  conditions 

int  c»  k;  //  and  set  test  mask 

for  (c=0;  c < numcdn;  C++)  { 

qens i q ( ) ; 
out  code (" i f (") ; 
outcodeCcstublcl  .cltr); 
out  code ("){"); 
genduD ( ) * 

out  code ( "ddb  =1  " ) ; 

outoct(k=(01  <<  (15-c))); 

putc ( ' ; ’ » outp) ; 

putc(TA8,outo); 

outcode("ddc  =&  "); 

out oc t ( nk  ) ; 

pu t c ( ' ; ' » ou  t p ) ; 

PUtcC ' 1 ' fOUto); 


i n i t va  r ( ) { 

fotr  s free; 
i no  = & i nbu  f . i Ob  f C } 
outP  = iou t bu f . i OP f d ; 

) 


//  initiali^e  variables 


k i 1 1 e K ( ) ( 

i nt  c ; 
fflush(outp); 

while  ((c=eatall())  !=  TOKM) 
run ( ) ; 

} 


//  kill  execut i on 


//  attempt  resvnc 


ma i n ( a rqc * a r ov ) int  arac  » char  **  arqv  ; < 

namfi le(arqc»arqv); 
if  ( cop VC  ode ( TOK \ ) ) ( 

0 r oc  t ab ( ) ; 
r un ( ) ; 

) 

fflush(outr); 

> 
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natiend()  ( //  check  for  end-of-name 

1 ot  c ; 

if  f(c=Gf)C)  ==  EOF)  thatsit(); 

if  (c=  = HLAt\iK  II  c = = TA0)  return(-l); 

if  (c==CRLF)  { 

1 i ne  ♦ ♦ » 
ret  urn ( - I ) ; 

) 

refurn(c)» 

> 

namfile  (arqc»arav)  //  fetch  names  for  files 

int  arqc  » //  from  command  line 

char  *arav()  ; ( 

int  k I 
i n i t V a r ( ) » 
i f ( a r qc  < ? ) i 

if((k  = fcreat("d.ta0.c"»outo))  ==  -1) 
faterr(l»arav[0)  ); 

} 

else  i f ( arqc  ==  ^ ) ( 

if((k  = f c r ea t ( "d . t ab . c " » ou t D ) ) ==  -1) 
faterr(l,arqvtl)  )» 
if((k  = f open ( a rqv  ( 1 ] f i no  ) ) - - -1) 
faterr(<?»arqv(l)  )» 

) 

else  < 

i f ( ( k = f oren ( a rqv  1 1)  > i np  ) ) ==  -1) 

faterr(<?,arnvtlJ  )J 

if((k  = f C rea t ( a rqv  (2 1 , out p ) ) ==  "1) 
faterr(5»arqv[?l  )» 
i f ( arqc  > 5 ) i 

printf(" Trash  in  command  line  ::  %s\n"»arqv(3]); 

} } } 
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namsubf)  { //  cooy  subroutine  name  to  outout 

i nt  C r k ; 

if  ( ( c =gobb 1 e ( ) ) = = CRLF  ) fsuberr(l);  //  missing  name 

gutc (crouto) ; 

noname  = FALSE; 

for  (k  = l ; Ic  < 9 ; k + t)  ( 

if  ( ( c = namend ( ) ) < 0)  { 

//  negative  return  indicates  end 
oarmlist();  //  copv  parameters 

return;  //  normal  return 

> 

putc(c»outp) ; 

> 

fsuberr(2);  //  name  too  long 

wh i 1 e ( ( C = namend ( ) ) >=  0)  ; 

oarmlistf); 

) 


outate(c)  int  c ; i 
i nt  k ; 
i f (k  = (c>>3)  ) 
out  at  e ( k ) ; 

putc((c’-C8  t ’O')»outp); 


> 


//  outout  octal  digits 


outcode(p)  char  *c  ; { //  outout  a string 

w h i 1 e ( *o ) 

pu  t c ( *p  + + f ou t p ) ; 

} 


outdec(c)  int  c ; ( 

i nt  k ; 
if  (k  = c/10) 
out  dec ( k ) ; 

putc((c%l0  + 'O')»outo); 


} 


//  outout  a decimal 


outoct(c)  int  c ; ( //  output  an  octal  number 

i nt  k » t ; 
putc ('O' »outp) ; 
if(c>=0)  outate(c); 
else  < 

putc ( ' I ' »outp) ; 

c =&  (t=077777); 

for  (k=12;  k>=0;  k=k-3)  < 

outc(((c>>k)  + 'O')»outp); 
c =&  (t=(t>>3)); 

} ) ) 


i 
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oact  (*)  int  x;  < //  opint  action  stub  and 

i nt  j ; //  ent  ry  H St 

j = o; 

printf("\nlt-32.32sa"*  astub(x)  ,a1tp)J 
whileCj  <=  (pumruie  ~ 1)) 

printf("  %c"»  as t ub  ( X ) . aen t py  ( j + ♦ ] ) ; 

) 

oapmlistC)  < //  copy  papatretep  list  to  output 

i nt  c » 

while  ((c=GNC)  > EOF  c !=  '(')  ( 

DUtC (c ,OUtp) ; 

if  (c==CRLF)  line++; 

} 

i f (c  = ='  ( ' ) ( 

DUtc('{'»OUtD); 

outc (CRLF  »outo) r 
return  f 

> 

ppintfC"  ERROR  invalid  papametep  1ist.\n"); 

t hat  s i t ( ) / 

> 


DELTRANS  SOURCE  CODE 


ptable  ()  ( //  driver  to  print  table 

i nt  i ; 

print  f("\nTABLE  SU'^'^'ARY  F0LL0>.S\n"  ) ; 
pr  i nt  f ( "\nT  ABLE  fJUPBER  Xd  . \n " , t abno ) ; 

printf("nu"'hpr  of  conditions  = %d\n"»  numcdn); 

orintf("nu'rber  of  rules  = Xd\n"»  nunrule); 

printt("nu'rber  of  actions  - %d\n"»  numact)» 

pr  i nt  f ( "\ni'.s5'.?Rs\n"  , "CONDITIONS;",  "RULES:"); 
forCi  = O;  i <=  nurcdn  - i;  i++)  pcond(i); 
pr jnt  f ("\n\nACTIONS:\n")  ; 

for(i  = 0;  i <=  nun-act  - i;  i-t+)  pact(i)j 
print  f("Vn"); 
i f ( noe 1 se ) 

pr i nt f ( " ****  MISSING  ELSE/ERROR  ACTION  ****"); 
else  if  (eeac  t [ 01 ) 

print f ("ELSE/ERROR  ACTION  ; %s  " , &eeac t [ 0)  ) ; 

e 1 se 

printfT"****  NULL  ELSE/ERROR  ACTION  ****"); 
printf("\n"); 


reiniti)  { //reinitial izevariables 

i nt  c ; 

enun  - nexta  = nextc  = nijmact  = 0; 

nunncdn  = nurnrule  = sumact  = sutrcdn  = 0; 

noelse  = nooec  = noname  = TRUE; 

i neons i s = FALSE; 

parsact=COMD; 

pbak  = oeek  - 

fptr  = free; 

for  (c  = 0;  c < MAXRULE  ; c-*-  + ) i 

rulefc)  = rmasktc)  10)  = rmaskic)  111  = 0; 

> 

for  (c  = 0;  c < BIGINT  ; c-t-*-)  ( 

f ree (c ] . ac t o t r = f ree fc) . ac t 1 t rs  = 0; 

) } 

run()  i //  driver  for  nultiole  table  coding 

while  (copvcode ( TOKN ) ) { 

re i n i t ( ) ; 
proc  t ao  ( ) ; 

) 

ffluSh(outp); 
ex  i t ( ) ; 
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same pu 1 e ( a » r ) int  a*  b»  { 
char  n , p ; 
int  k ; 
k = - 1 ; 

tahile  (•«.♦♦  < numcin)  { 

n = cstut'[k].centryta]; 
p = c s t uh  ( k ) . cen t py tb]  ; 
Switch  (n)  { 

case  : 

break; 

case  'y'  : case  'S'  ; 

if  (R=='n' ! !p=='*') 
return(EALSF5  » 
break ; 


//  test  if  rule  a and 
//  rule  b are  identical 


case  ' n ' 


case  ' * ' 


if  (o=='v' : !n=='J') 
rerurn(FALSF)  ; 


> } 

return(TRUE); 


> 


//  set  ru  1 e masks 


setmask  ()  { 

int  i»  i»  orlist; 
or  1 i St  = 1 ; 

for(i  = Ofi  < numcdn;itf)  { 

for(j  = 0;j  < numrule;i++)  < 
orlist  =<<  (15-i); 
switch  (cstublil.centry(jl)  { 
case  ' y ' : case  'S'  : 

rmask[jl  !0]  =!  orlist; 

break; 

case  'n'  : case  : 

rmaskCjltl)  =!  orlist; 
break; 
default  ; 

rmask(j][0I  =!  orlist; 
rmask(jl(l)  =1  orlist; 


) > 


orlist  = 1 ; 
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strcopyCk»p»s)  int 

k; 

char  *Dt 

*s;  { 

//  copy  string 

i nt  i » C ; 

// 

f rom  i nput  to  o 

o 

II 

while  Ct+i  < k) 

{ 

if  CCc=GNC) 

= = 

DELIM) 

break ; 

if  Cc==CRLF) 

1 i ne  t ♦ ; 

else  if  (c==  EOF)  thatsitC); 
*D  + + =c ; 

} 


*p 
i f 


= null; 

(i>  = k *!,&  (c=GMC) 
if  (c==  EOF) 
printfC  ERROR 
Drintf("Inva1  ia 
k i 1 1 ex ( ) ; 


:=  DELIM)  { 
t hat  s i t ( ) ; 

*soi*  "); 

%s  stub  line  % 


.\n",s»line); 


} ) 


SU"err(n»c)  char  *c»  < //  print  number  errors 

orintfC"  ERROR  Xs  number  of  Xs  not  "»n,c); 
printf("as  specified  in  ootion  sec t i on . \n " ) ; 
printf("\nExecution  terminated. \n"); 
k i 1 1 e X ( ) ; 


thatsit()  { //  exit  for  invalid  end-of-file 

printfC "Unexpected  END  OF  FILE  encountered/  "); 
orintfC "execution  terminated.Nn"); 
fflushCoutp); 
ex i t C ) ; 

> 

tossline  Cc)  int  c ; C //  toss  away  rest  of  line 
if  Cc!=CRLF)  while  C C c = qobb 1 e C ) ) 1 =CRLF  ) ; 

} 


totruleCn)  int  n;  { //  sum  the  number  of  simple 

int  k,  t;  //  rules  in  a table  rule 

t = o; 

for  Ck  = 0;  k < numcdn  7 k ♦ ♦ ) { 

if  ( c s t ub  ( k 1 . cen t r V In]  ==  '-') 

t + + ; 

) 

return  Cl  <<  t); 
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yyaccpt  ()  { //  accepted  table  routines 

i n t i ; 
pt  ab I e ( ) ; 
i f (enum ) 

return; 

i f ( amb i qc  k ( ) ) 
return; 
setmask  ( ) ; 
qencode { ) ; 

} 

yyerror(s)  char  *s  ; { 

printfC’  ERROR  *X0"); 
if  (parsact  ==  TLIST) 
printf ("2"); 

else  if  (parsact  ==  ALIST) 
p r i n t f ( " 3 " ) ; 

else 

p r i n t f ( •■  1 " ) ; 

printf("*  statement  syntax 
k i 1 I e X ( ) ; 


yylex()  ( //  scanner 

extern  int  yylval; 
i nt  c ; 

switch  (parsact)  ( //  f 1 aq  for  scanner 

case  TLIST  : 
case  AL IS  r ; 
case  MU '-I  : 

case  DIGIT  : 

i f ( (c=eatc  ( ) ) >=  ’O*  c <=  'P')  ( 
yylval  = c - 'O’  ; 

while  ((c=GMC)  >=  'O'  8,11  c <=  'P')  i 
yylval  = yylval  * 1 0 c ” '0'  ; 

if(yylval  > numrule)  badloaic(’’L0y"); 

} 

if  ((pbak  = c)  ==  CPLF)  linet+; 
else 

i f (c==  EOF)  thatsi t ( ) ; 
parsact  = (parsact  ==  ALIST  ? MUW  : DIGIT) 
return (parsact  ) i 

) 

return(c); 
default  ; 

return(parsact  ) ! 

} > 


//  syntax  error  handler 


line  %d.\n",line); 
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